Subject: [rohc] [SigComp] INPUT-BITS

From: "Gustav E" <[email-masked]>
Date: Wed, 19 Apr 2006 16:44:40 +0200

Hi all,

I've experienced some issues with the behaviour of the INPUT-BITS UDVM 
instruction.
At a more specific level, the issue is of how a UDVM should behave if the 
length operand is set to zero.
According to 3320 it's valid:
" The length operand indicates the requested number of bits.
   Decompression failure occurs if this operand does not lie between 0
   and 16 inclusive."

Our implementation simply ignores the instruction, i.e. no result is written 
into the destination, whereas a compressor might rely on a behaviour where 
0x0000 is actually written to the destination.

I've tried to find an answer in the RFCs / implementation guide draft, but 
haven't been able to see a specific answer to the problem.

What's your view on this?

Sorry if I've missed something in previous discussions.

BR,
/Gustav E

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Apr 2006 18:28:07 +0300

Hi Gustav,

> I've experienced some issues with the behaviour of the INPUT-BITS  
> UDVM instruction.
> At a more specific level, the issue is of how a UDVM should behave  
> if the length operand is set to zero.

The RFC says nothing about treating the length of 0 in any way special.

    the requested bits are
    interpreted as a 2-byte integer ranging from 0 to 2^length - 1

As length is 0, we have a 2-byte integer ranging from 0 to 2^0 - 1,  
i.e. 0 to 0.
That 2-byte 0 needs to be copied to the memory at %destination.

This even is true when the input bytes have already been exhausted --  
only under the condition that new data would be required beyond the  
one supplied, "Instead the UDVM moves program execution to the  
address specified by" @address.

Gruesse, Carsten