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

From: "Price, Richard" <[email-masked]>
Date: Wed, 13 Mar 2002 15:33:16 -0000

> >   0   1   2   3   4   5   6   7
> > +---+---+---+---+---+---+---+---+
> > | 1   1   1   1   1 | Length=0  |
> > +---+---+---+---+---+---+---+---+
> > |           MSBs of X           |
> > +---+---+---+---+---+---+---+---+
> > |           LSBs of X           |
> > +---+---+---+---+---+---+---+---+
> >
> > This would save having to put an explicit JUMP instruction at the beginning
> > of all downloaded UDVM bytecode.
> 
> A JUMP may not be necessary in many cases, in which case this would cost two
> bytes more than necessary.
> If a JUMP is necessary, it typically costs the same two bytes (unless the
> code is large).
> So I'm not sure that's a win.

We'd need a bit more than a JUMP instruction in order to load the code into a
different memory position than 6; in fact we'd also have to include a COPY
instruction to move the code into the correct location before we execute it.
This will cost 4-5 bytes more than the above header unless we can assume that
the code will always be located at Address 6.

> The only reason I know to load code at a different position than 6 is that
> %-style operands make it cheaper to address 16-bit quantities in low memory
> (0..128).

This is what I forgot about when making the original assumption that all code
would be located at Address 6.

> Couldn't we fix X at, say, 0x80?

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.

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Wed, 13 Mar 2002 16:50:11 +0100

> case where all 16-bit quantities are placed in a contiguous block

You could have the space all after the "cheap" space?

There is no need to be overly sparing with the UDVM space.

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.

Possible remedy:
1) provide a way to designate some of the packet for the input space in the
no-reference case of flexible mode.
2) provide a way for the UDVM code to designate core space as input space;
also provide and end marker.

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.

Gruesse, Carsten

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