Subject: RE: [rohc] some comments on sigcomp-05

From: "Price, Richard" <[email-masked]>
Date: Fri, 15 Mar 2002 10:04:56 -0000

> > I believe that this will generally cost more bytes than the 2 bytes it is saving.
> > For example, algorithms that need more than 128 different 16-bit quantities (i.e.
> > DEFLATE or better) will need to put the first 128 quantities before the code and
> > the remainder after the code. Initialising these quantities will require two
> > MULTILOAD instructions, which already costs 3 additional bytes compared to the
> > case where all 16-bit quantities are placed in a contiguous block in front of the
> > code.
> 
> You could have the space all after the "cheap" space?
> 
> There is no need to be overly sparing with the UDVM space.

If we put all the 16-bit quantities after the cheap space then we lose the ability
to cheaply reference the first 128 quantities. This will definitely cost more bytes
than the 2 bytes it is saving.

> I do see a problem here, though.
> With the UDVM, we currently have to spaces:
> -- UDVM memory ("core"), which is addressible, but not available for
> sequential bitwise reading by "INPUT-..." style instructions, and
> -- UDVM input space, which can be read sequentially and has a defined end,
> but is not addressible.
> 
> In flexible mode, if a state reference is present, the rest of the packet
> stays in input space.
> If no state reference is present, all of the packet goes into the core.
> There is no end marker in this case.
> 
> It's not clear to me this makes sense.

The SigComp header doesn't gel properly with the remainder of SigComp just yet.
For example the assumption that the header is parsed in the dispatcher is
incompatible with the SigComp architecture of Figure 1, because it needs an
extra interface between the dispatcher and the state handler. The assumption
that the entire SigComp message goes into the core UDVM memory is also outdated;
with the current SigComp design the message should remain in "input space" until
requested via the appropriate INPUT instruction.

> Possible remedy:
> 1) provide a way to designate some of the packet for the input space in the
> no-reference case of flexible mode.

This strikes me as a good approach. How about providing 4 additional bytes in
the no-reference case: 2 bytes containing the start location of the code and
2 bytes containing the length of the code? This means that we can copy the
bytecode for our chosen algorithm into the UDVM memory, but leave the remainder
of the compressed message in the input space as the algorithm expects. I believe
that these 4 bytes will easily pay for themselves by simplifying the bytecode
for the chosen algorithm.

We could even do variable-length encoding on the above 4 bytes if the overhead
is a concern.

> 2) provide a way for the UDVM code to designate core space as input space;
> also provide and end marker.

This approach is more complicated because the input space is sequential and
bit-aligned whereas the UDVM memory is direct access and byte-aligned.
Instructions like INPUT-HUFFMAN are greatly simplified if they only apply
to input space rather than to an arbitrary bit location within the UDVM memory.

> Also, INPUT-BYTECODE is strange in that you have to know how much is out
> there; you can't just say "give me what you have" except through a binary
> search.

Why not just use the following bytecode?

:loop
INPUT-BYTECODE 1 $destination end_of_message
ADD $destination 1
JUMP loop
:end_of_message

If it would be useful to add a specific "give me what you have" instruction
however, then I can't see a problem with adding one.

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 15 Mar 2002 11:13:32 +0100

> We could even do variable-length encoding on the above 4 bytes if

It just struck me that you could encode the *end* of the code (byte after
code) in a 2^n style, using 4 bits.
The start (load point and initial PC) would then be computed by 2^n-length.
Requires position-independent code (which is usually the case) and/or a
multi-pass assembler, but then I've already shown how easy those are :-)
The 4 bits would leave enough space for the length in this and another byte
for most applications.

Of course this works best if we adopt cabo-15.

Gruesse, Carsten

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