Subject: Re: [rohc] SigComp: input_bit_order question...

From: Zoltan Barczikay <[email-masked]>
Date: Fri, 21 Jun 2002 12:42:43 +0200 (MEST)

Mark,
thank you for your answer. Most probably you are right about the P=F=1 case:

> If your current input byte is:
> 	00100000

> ... reading from the bit 3rd from the left, with 
> P = 1, the bits 1, 0, 0 are passed from the dispatcher to the input 
> instruction, so with the F-bit you get:
> 
> F=0, MSB->LSB gives 100 = 4
> F=1, LSB->MSB gives 001 = 1

But carefully re-reading the draft, I come to think that possibly we get

  000 

in this case, as P=1 means that the input byte 0010000 should be read 
starting from the LSB, that is, when requesting 3 bits, we get 000:

  "The P-bit controls the order in which bits are passed from the
   dispatcher to the INPUT instructions. If set to 0, it indicates that
   the bits within an individual byte are passed to the INPUT
   instructions in MSB to LSB order. If it is set to 1, the bits are
   passed in LSB to MSB order."
   
So I think P and F dont simply negate each other.

I have the same problem with P and H. When requesting additional bits
at executing an INPUT-HUFFMAN instruction, when should we reverse
the bits and bytes? 

Possibilities:

1.) We could "build" the whole 16-number first, then apply the P-bit, 
    that is, reverse each of the two bytes in place.
    
2.) We could reverse each byte in place in the dispatcher, before
    chopping them into chunks of bits.
    
Of course, if H=1, we should reverse each chunk of bits before using them,
ie, before comparing them to the upper & lower bounds.

What do ye think?

Zoltan.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 21 Jun 2002 13:03:58 +0100

Some more comments...

> starting from the LSB, that is, when requesting 3 bits, we get 000:

Yes, if you were to read from *the* least significant bit.  However, 
that's why I said 'reading from the bit 3rd from the left' [i.e. the 
'1'], so that I could use the same input byte.

Probably a confusing example -- sorry!

(If you like, think of the input byte being 00100001...)

> So I think P and F dont simply negate each other.

No, they don't negate each other.  You have 4 cases, which I could 
describe as:
	P=0, F=0
	P=0, F=1
	P=1, F=0
	P=1, F=1

Or, alternatively
	Read bits left to right, bit order is same
	Read bits left to right, bit order is swapped
	Read bits right to left, bit order is swapped
	Read bits right to left, bit order is same

> at executing an INPUT-HUFFMAN instruction, when should we reverse

Yes, the HUFFMAN one caught me out a bit as well!  However, it basically 
follows the same rules, and the rule for combining bits to build the 
Huffman token is explicitly written into the algorithm description.

>     that is, reverse each of the two bytes in place.

The P bit is applied first.  It controls the order in which bits are 
read.  You never apply the P-bit after reading data.  I don't understand 
why you're talking about a 16-bit number.  When dealing with inputting 
bits, the number of bits that are reversed (if need be) is the number 
that have been read.

>     chopping them into chunks of bits.

But you don't actually need to reverse the bytes in the dispatcher, 
although I guess that you could think of it that way.

However, that only manages the P-bit, you still need to apply the H-bit.

> ie, before comparing them to the upper & lower bounds.

Be careful here!

Each read that the INPUT-HUFFMAN instruction performs acts like 
INPUT-BITS (except that it uses the H-bit instead of the F-bit).  So 
imagine I have a INPUT-HUFFMAN instruction that reads 2, then 3 bits, 
for a total possible length of 5 bits.

Then the first read is for 2 bits, which is done exactly as described 
for INPUT-BITS before.  Say this gives us the value '00'.

If this doesn't match, the next 3 bits are read; again, as described for 
INPUT-BITS.  So, this might give us, '100'.

Now, regardless of the P and H bits, each new set of bits are always 
added as the least significant bits (as described in steps 2. and 3. of 
the INPUT-HUFFMAN instruction).  So we now get '00100' as our input to 
compare against the bounds.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)