Subject: [rohc] SigComp User Guide, deflate bytecode

From: Herve Siegrist <[email-masked]>
Date: Mon, 14 Mar 2005 16:49:41 +0100

If you saw that one, please forget about it, I was quite mistaken
and everything is ok...

I had simply missed the two large "pad" directives which make
the code actually start at the proper address... Just had to
load it at the right address, my problem (even though, to be
picky, that was not really said in the draft)...

Sorry about the noise on this one, please forget you ever saw it...

Thanks,
Herve.

 > I am testing my UDVM against the bytecodes provided in the
 > draft SigComp User Guide for the sample algorithms, and I
 > am getting into some trouble with the DEFLATE bytecode.
 >
 > From the assembly code, it appears that the bytecode is, as
 > for other bytecodes in this draft, meant to be loaded at
 > UDVM address 128.
 >
 > However, this bytecode starts with a MULTILOAD instruction
 > which writes 122 words at address 64, hence writing bytes
 > at addresses 64 to 307 inclusive.
 >
 > The bytecode for the MULTILOAD instruction however occupies
 > addresses from 128 to 285 inclusive.
 >
 > As a result, it seems to me, unless I missed something big
 > (again...), that the execution of the MULTILOAD instruction
 > causes a decompression failure as it overwrites its own
 > code (and even more...). At least, that's what happened to
 > me the first time around...
 >
 > Is there really something wrong with this bytecode?
 >
 > Actually, the problem does not really seem to be with the
 > bytecode itself, but more with its assembly: loading the
 > bytecode at address 320 (destination field = 4) instead of
 > 128 makes everything work just fine...
 >
 > Hence, seems to me that replacing the "align (64)" in the
 > DEFLATE assembly code with a "at (320)" should resolve the
 > issue?
 >
 > One thing I still worry about though: as the circular buffer
 > is right after the bytecode, would this circular buffer
 > overwrite an eventual static dictionary (SIP?) loaded at
 > address 1024 as recommended in the draft (not sure what the
 > circular buffer size will be and if there will be enough
 > room left after changing the bytecode start address)?
 >
 > While I'm at it, just one more little question on that topic:
 > what are the extra "0000 00ff ff00" bytes added at the end of
 > the sample message provided in the draft? They do not seem to
 > relate to actual compressed data, and the sample message
 > decompresses just as well without them...
 >
 > Herve Siegrist.

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 14 Mar 2005 16:52:08 -0000

Hi Herve,

> decompresses just as well without them...

You're right, it does.  
They don't break anything by being there because although the sentinel of 7
bits of zero is not necessary (as the draft says) it just happens that in
this message the total number_of_bits_needed mod 8 = 1 so we do have the 7
bit sentinel to make the message byte aligned.  Any bytes beyond it are
ignored.

I'm not sure why the bytes are there and they're not needed, so I'll remove
them.  

Thanks for pointing it out.

Best regards,

Abbie

---

From: "Lepine, Jean-Pierre" <[email-masked]>
Date: Thu, 31 Mar 2005 16:28:03 -0500

Hi,
 
I hope I'm not too late but I just saw a posting dated from 14 Mar 2005 (see
below). After reading the User Guide, I thought the extra "ff ff" may have
been placed there for the sake of record marking in a stream-based
application. Does this make sense ?
 
Jean-Pierre

Hi Herve,

You're right, it does.  

Best regards,

Abbie
> Rohc at ietf.org
<https://www1.ietf.org/mailman/listinfo/rohc> 

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
<https://www1.ietf.org/mailman/listinfo/rohc>