Subject: [rohc] sigcomp issue sugar-3

From: "Price, Richard" <[email-masked]>
Date: Mon, 22 Apr 2002 15:22:54 +0100

> Any reason why we don't put stack_free down in low mem as
> well? (In any case, we need to define what the terms
> "stack_free" etc. mean; the text in 9.2.3 seems to presume
> a certain location that may no longer be consistent with the
> load addresses available.) Where does the 56 come from? 

Hi,

The reason that stack_location is stored separately from
stack_free is that the former typically contains a fixed value
that will be retained between compressed messages, whereas the
latter contains a temporary value that will be reset to 0
before decompressing each message. Therefore, it is useful to
store stack_free together with the other temporary data (such
as the stack itself), outside of the memory area that will be
saved as state between compressed messages. I prefer this
mainly for "architectural reasons" as it keeps the temporary
and permanent areas of UDVM memory cleanly separated, but it
can also reduce the size of the uploaded bytecode as stack_free
does not have to be reset to 0 manually before decompressing
each message.

The value 56 is part of the following sentence:

"Decompression failure occurs if stack_free is ever decreased
below 0, or if one of the above instructions is encountered and
the value of stack_location is smaller than 56 (this prevents
the stack from overwriting the stack_location register)."

Address 56 is just the memory address immediately after the
stack_location register itself; we should probably rewrite the
above sentence to make this clear.

Regards,

Richard

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 22 Apr 2002 18:04:17 +0200

Hi Richard,

I think some of the confusion may stem from calling the stack pointer
stack_free, when in reality we don't have a mechanism that checks
there is enough space left on the stack (i.e. there are enough "free"
locations on the stack).  Also, the notation stack[stack_free] is only
defined by example, AFAICT.

> does not have to be reset to 0 manually before decompressing

OK, I presume your point is that stack_free starts out at zero, so you
can implicitly initialize it by allocating it in virgin UDVM core, in
contrast to stack_location, which definitely needs to be initialized
according to the decompressor's memory layout.

> above sentence to make this clear.

Why is it more important to protect the stack_location register than
anything else?  In a resilient architecture, I'd imagine a stack_limit
(or stack_size) register.  Now, we don't necessarily need that, but I
still don't quite understand why my stack cannot start below 56 if I
want it to.  Is it just to have a way to detect address wraparound?

(Also note that "below 0" does not mean too much in an unsigned
arithmetic setting.)

Gruesse, Carsten

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