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

From: Zoltan Barczikay <[email-masked]>
Date: Fri, 21 Jun 2002 07:51:23 +0200 (MEST)

Hello,
I am working on a SigComp implementation.

I know you have discussed already the new "input_bit_order" register,
but I still have a question:

The P bit is valid for all the three instructions: INPUT-BYTES, INPUT-BITS,
INPUT-HUFFMAN. It is clear how it works in the case of INPUT-BYTES.
But what happens eg with INPUT-BITS? 

Suppose that both the P and F bit are set. Suppose we request 3 bits:
"001". Then first we should reverse the bit order because F=1, so we get
the number "100". Then we should store it at a location in UDVM memory,
as hexa 0004, but we should again reverse each byte because P=1.

So in the end we store the two-byte value 0020. (20 is bit-reversed 04.)
Is this correct? Should we reverse it twice if P=F=1?

It would be much simpler if the P bit influenced only the INPUT-BYTES, 
but its not the case.

Thanks in advance for any help,
Zoltan Barczikay.

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

---

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

Hi Zoltan,

Some comments (and hopefully clarifications), inline.

Cheers,

Mark.

> as hexa 0004, but we should again reverse each byte because P=1.

When you say that the 3-bits are '001', it's not quite clear what you 
mean.  But I'll come back to that.

Personally, I find talking about 'reversing the bit order' confusing. 
F=1 does *not* mean reverse the bit-order.  F=1 means interpret the bits 
received from the dispatcher as in the order LSB -> MSB.

The P-bit affects data passed from the dispatcher to the INPUT 
instruction.  You certainly don't reverse the data again because of the 
P-bit.  (And you wouldn't reverse each byte independently, anyway).

Let me try an example:

If your current input byte is:
	00100000
If you are reading from the left-most bit, with P = 0, the bits 0, 0, 1 
are passed from the dispatcher to the input instruction.

F=0, these are seen as MSB -> LSB, so you get 001 = 1
F=1, these are seen as LSB -> MSB, so you get 100 = 4

With the same input byte, 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

Another way of thinking about this is to see that if the next 3 bits to 
be read appear as 001 in the input byte, then these bits will be 
transferred to the UDVM as 001 if P and F are the same.  However, if P 
and F are different, then the bits need to be reversed (giving 100).

This is just how I think of it, however, and I don't know if anyone else 
will find it helpful!

> It would be much simpler if the P bit influenced only the INPUT-BYTES, 

Well, it would be much simpler if we didn't have to worry about this 
bit-order business at all!  Unfortunately, the designers of compression 
algorithms have used an eclectic selection of bit formats, which the 
UDVM needs to cope with!

-- 
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)