Subject: [rohc] SigComp torture tests

From: "Price, Richard" <[email-masked]>
Date: Wed, 6 Nov 2002 16:45:01 -0000

Hi,

I just noticed that the following draft is now available:

http://www.ietf.org/internet-drafts/draft-price-rohc-sigcomp-torture-tests-00.txt

This draft contains a set of "torture tests" designed
specifically to help debug implementations of SigComp.
Each UDVM instruction is tested in turn, focusing in
particular on the boundary and error cases that are not
usually encountered when running well-behaved code.

I'd be grateful for feedback on this draft - are the
tests useful to implementers, and are there any other
cases that the tests should cover?

Regards,

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

---

From: Chan Kwang Mien <[email-masked]>
Date: Thu, 07 Nov 2002 12:50:12 +0800

hi Richard,

i have a question on the test for Bit Manipulation. i don't seem to
get the expected output as stated in the draft. i think the reason being 
that i used 2 bytes
to represent the 'start' parameter in the AND instruction while probably in 
your case,
you have used 3 bytes.

in my case, for the instruction AND ($start, ....) the byte codes are

    01 80 FF  ......

maybe in your case,

    01 C0 00 FF .....

could you clarify ? Thanks !!

regards,
Kwang Mien

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 7 Nov 2002 10:27:11 -0000

Hi Kwang Mien,

Looking at Figure 9 in SigComp, a 2-byte reference operand can only
point to "even" memory addresses. In the bytecode AND ($start , ....)
however, the reference "start" needs to point to Address 255. So it
isn't possible to encode this reference using only 2 bytes.

The bytecode produced by your assembler is actually pointing to
Address 510 rather than Address 255, so I suspect that there's a
"divide by 2" statement missing somewhere.

Hope this helps!

Regards,

Richard

> -----Original Message-----
> From: Chan Kwang Mien [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 4:50 AM
> To: Price, Richard; [email-masked]'
> Subject: Re: [rohc] SigComp torture tests
> 
> 
> hi Richard,
> 
> that i used 2 bytes to represent the 'start' parameter in the AND
> instruction while probably in your case, you have used 3 bytes.
>

---

From: [email-masked]
Date: Thu, 7 Nov 2002 17:48:37 -0600

Richard,
   some editorial comments. In your draft, does "at(x)" implies at address x in the byte code? If that's true, i feel that it would be more appropriate  if you use .align/.pad as they were the terms used in sigcomp user guide.  
  Draft explicitly states that code is given using sigcomp assembly language and we don't have "at(x)" in the user guide.

thanks,
Narendra

-----Original Message-----
From: ext Price, Richard [mailto:[email-masked]]
Sent: 06 November, 2002 10:45 AM
To: [email-masked]'
Subject: [rohc] SigComp torture tests

Hi,

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 8 Nov 2002 10:25:57 -0000

Hi Narendra,

Your guess for the meaning of "at(x)" is correct. It's a useful
directive for moving bytecode to a specified memory address - we
agreed a while back to add it to the assembly language as using
"align" or "pad" for the same task is clumsy.

The "at" directive is explained in the updated SigComp User
Guide, which doesn't seem to be available on the IETF website
yet. Until it appears I've made a copy available at:

http://www.epic.roke.co.uk/epic/draft-price-rohc-sigcomp-user-guide-01.txt

Regards,

Richard

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 11:49 PM
> To: Price, Richard; [email-masked]
> Subject: RE: [rohc] SigComp torture tests
> 
> 
> Richard,
>    some editorial comments. In your draft, does "at(x)" 
> implies at address x in the byte code? If that's true, i feel 
> that it would be more appropriate  if you use .align/.pad as 
> they were the terms used in sigcomp user guide.  
>   Draft explicitly states that code is given using sigcomp 
> assembly language and we don't have "at(x)" in the user guide.
> 
> thanks,
> Narendra
> 

Regards,

Richard