Subject: [rohc] Torture Test - 2.12. INPUT-BYTES

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Mon, 20 Jan 2003 12:55:09 +0100

Hi,

I have problem with the output of test 2.12 (INPUT-BYTES):

The output area lies from 72 (byte_copy_left = 72) to 75 inclusive (byte_copy_right = 76). Initially input_bit_order = 0.

Let's see the execution of the code step by step:

* INPUT-BITS ($input_bit_order, result, end_of_message) 

this line inputs 0 bits, so the output is 0x0000 (OK)

* ADD ($input_bit_order, 2) 
  REMAINDER ($input_bit_order, 7)

input_bit_order = 2, i.e. H = 1 that does not impact the next INPUT-BYTE

* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
  OUTPUT (output_start, $input_bit_order) 

inputs 2 bytes, so the output is 0x932E (OK)

* ADD ($input_bit_order, 1)

input_bit_order = 3, i.e. H = 1 and P = 1, then start again

* INPUT-BITS ($input_bit_order, result, end_of_message)

inputs 3 bits in MSB to LSB order (001), so the output is 0x0001 (OK)

* ADD ($input_bit_order, 2) 
  REMAINDER ($input_bit_order, 7)

input_bit_order = 5, i.e. F = 1, P = 1, but for INPUT-BYTES only P is interesting

* INPUT-BYTES ($input_bit_order, output_start, end_of_message)
  OUTPUT (output_start, $input_bit_order) 

The remaining 5 bits of AC are discarded. The 5 bytes read are: 8e 66 1b f6 8d. As the fifth bytes overwrites the first one in the memory, the output area contains 8d 66 1b f6.  The five output bytes should then be: 8d 66 1b f6 8d. The torture test doc instead says: b166 d86f b100 ...

Am I again mistaken?

BR/Zacco

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 20 Jan 2003 13:50:08 -0000

Hi Zacco,

<snip>
>The remaining 5 bits of AC are discarded. The 5 bytes read 
>are: 8e 66 1b f6 8d. As the fifth bytes overwrites the first 
>one in the memory, the output area contains 8d 66 1b f6.  The 
>five output bytes should then be: 8d 66 1b f6 8d. The torture 
>test doc instead says: b166 d86f b100 ...
>
Input bytes doesn't take any account of input_bit_order.  In particular, it takes no notice of the P bit.
The 5 bits of AC are discarded, as you say.  Then the next 5 bytes of the message are read straight in - that is 71 66 d8 6f b1 from the compressed message.  Then the output area contains b1 66 d8 6f and the output becomes b1 66 d8 6f b1.  In using INPUT-BYTES there is no swapping the order of the bits.  

I hope this helps.

Best regards,

Abbie

---

From: "Lajos Zaccomer (ETH)" <[email-masked]>
Date: Tue, 21 Jan 2003 09:24:12 +0100

Hi,

Thanx for the answers! INPUT-BITS all right now.
However, I have doubts on what you said about INPUT-BYTES. The RFC says (page 31): "The P-bit controls the order in which bits are passed from the dispatcher to the INPUT instructions." As one byte is comprised of 8 bits, it is quite straightforward to understand this way. I must say that the RFC is again not clear enough!

Also, check this mail on the list:

From: "West, Mark (ITN)" <[email-masked]>
To: Zoltan Barczikay <[email-masked]>
Cc: [email-masked]
Subject: Re: [rohc] SigComp: input_bit_order question...

Zoltán's mail stated that P applies to INPUT-BYTES as well, which was not objected by Mark or anybody else.

According to the RFC, both explanations seem acceptable to me. But what is the truth?

BR/Zacco

-----Original Message-----
From: Surtees, Abigail [mailto:[email-masked]]
Sent: Monday, January 20, 2003 2:50 PM
To: 'Lajos Zaccomer (ETH)'; [email-masked]'
Subject: RE: [rohc] Torture Test - 2.12. INPUT-BYTES

Hi Zacco,

<snip>

I hope this helps.

Best regards,

Abbie

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 23 Jan 2003 09:04:23 -0000

Hi Zacco,

The INPUT-BITS and INPUT-HUFFMAN sections both reference section 8.2 (the input_bit_order section) whereas the INPUT-BYTES does not.  The reference you make to page 31 is written within section 8.2, the second paragraph of which begins 'Note that the INPUT-BITS and INPUT-HUFFMAN instructions receive a stream of individual compressed bits...' and doesn't mention INPUT-BYTES.

I think the intention of the authors was that the P bit should not affect INPUT-BYTES but I think it could be made clearer.  

Best Regards,

Abbie

>From: Lajos Zaccomer (ETH) [mailto:[email-masked]]
>Sent: 21 January 2003 08:24
>To: Surtees, Abigail; [email-masked]'
>However, I have doubts on what you said about INPUT-BYTES. The 
>RFC says (page 31): "The P-bit controls the order in which 
>bits are passed from the dispatcher to the INPUT 
>instructions." As one byte is comprised of 8 bits, it is quite 
>straightforward to understand this way. I must say that the 
>RFC is again not clear enough!
>
>Zoltán's mail stated that P applies to INPUT-BYTES as well, 
>which was not objected by Mark or anybody else.
>