Subject: RE: [rohc] Implementors Guide for Sigcomp - a correction

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 28 Feb 2006 11:19:32 -0000

Hi John,

Very belatedly, but in time for the next version of the draft, how about
the following example for MULTILOAD (leaving the introductory paragraph
as is and altering the bytecode only to put circular_buffer and
udvm_memory_size as explicit labels):

"   at (64)

   :location_a                     pad (2)
   :location_b                     pad (2)
   :location_c                     pad (2)
   pad (30)
   :udvm_memory_size               pad (2)
   :circular_buffer                pad (2)

   align (64)

   MULTILOAD (location_a, 3, circular_buffer,
                   udvm_memory_size, $location_a)

   The step-by-step implementation would: write the address of
   circular_buffer into location_a (memory address 64); write the
   address of udvm_memory_size into location_a + 2 (memory address 66);
   write the value stored in location_a (accessed using indirection -
   that is now the address of circular_buffer) into location_a + 4
   (memory address 68).  Therefore, at the end of the execution by a
   correct implementation, location_c must contain the address of
   circular_buffer.
"

Any comments appreciated.  In the absence of comments by 3pm GMT on
Thurs, I will assume that the above is ok and submit the draft
accordingly.

Best regards,

Abbie

> -----Original Message-----
> From: John Barber [mailto:[email-masked]] 
> Sent: Tuesday, October 04, 2005 4:04 PM
> To: Surtees, Abigail
> Subject: RE: [rohc] Implementors Guide for Sigcomp - a correction
> 
> Hello again Abbie,
> 
> Sorry, you're absolutely right, there is no contradiction. I was
> misreading the "align 64" as meaning "at 64" hence I thought the
> instruction would be self-modifying. It makes sense now.
> 
> Perhaps a detailed commentary of the code would help to get 
> the message
> across?
> 
> My suggestion:
> 
> "In this example, the code is not self-modifying - the memory 
> locations
> taken up by the instruction opcode and operands are not modified.
> However, in the first step of MULTILOAD execution, the address of
> circular_buffer is stored in the two bytes at location_a, machine
> address 64. In the third step of the MULTILOAD execution 
> (processing of
> parameter $location_a), the value stored at location_a is 
> accessed using
> operand indirection, and the result of this operation is stored at
> location_c. For correct operation, the value stored at location_c in
> this example must be the address of circular_buffer. That is 
> to say, the
> evaluation of indirection for a MULTILOAD operand must be performed
> after the memory updates caused by previous steps of the MULTILOAD
> execution." 
> 
> ...but I'm sure you can improve on this.
> 
> Best regards, John
> 
> > -----Original Message-----
> > From: Surtees, Abigail [mailto:[email-masked]] 
> > Sent: 04 October 2005 15:19
> > To: John Barber; [email-masked]
> > Subject: RE: [rohc] Implementors Guide for Sigcomp - a correction
> > 
> > Hi John, all,
> > 
> > I don't think it does contradict section 9.2.2 - that's the 
> > section it's meant to clarify.  However, I can see the 
> > confusion so it probably needs to be clarified more clearly!
> > 
> > In section 9.2.2 "memory locations held by the instruction 
> > (including its operands) itself" means the memory taken up by 
> > the instruction and the 1-3 byte representations of its 
> > parameters.  It does not include any memory referred to by 
> > the parameters.  Consequently ':location_a' is not part of 
> > the instruction and so the instruction is not being overwritten.
> > 
> > Would the addition of the sentence 'The memory area that must 
> > not be modified by the execution is that between the byte of 
> > the MULTILOAD opcode and the final byte of the final 
> > operand.' add suitable clarification?
> > 
> > Best regards,
> > 
> > Abbie
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf 
> > > Of John Barber
> > > Sent: Tuesday, October 04, 2005 12:38 PM
> > > To: [email-masked]
> > > Subject: [rohc] Implementors Guide for Sigcomp - a correction
> > > 
> > > 
> > > Hi
> > > 
> > > This looks like an error in the document 
> > > http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-im
> > > pl-guide-0
> > > 5.txt:
> > > 
> > > See section 3.2 Multiload:
> > > 
> > > </quote>
> > > For example:
> > > 
> > >    at (64)
> > > 
> > >    :location_a                     pad (2)
> > >    :location_b                     pad (2)
> > >    :location_c                     pad (2)
> > > 
> > >    align (64)
> > > 
> > >    MULTILOAD (location_a, 3, circular_buffer,
> > >                    udvm_memory_size, $location_a)
> > > 
> > > 
> > >    Once the MULTILOAD has been executed, location_c must contain
> > >    circular_buffer.
> > > <quote/>
> > > 
> > > This contradicts Sigcomp Section 9.2.2 (last paragraph) 
> > which states 
> > > that a decompression failure should occur in the case of a 
> > > self-modifying MULTILOAD instruction (such as this is).
> > > 
> > > Regards, John
> > > 
> > > _______________________________________________
> > > Rohc mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/rohc
> > > 
> > 
> > 
> 

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

---

From: "John Barber" <[email-masked]>
Date: Tue, 28 Feb 2006 11:36:25 -0000

Hi Abbie,

That's fine by me.

Regards, John 

> Sent: 28 February 2006 11:20
> To: John Barber
> Cc: [email-masked]
> Very belatedly, but in time for the next version of the 
> draft, how about the following example for MULTILOAD (leaving 
> the introductory paragraph as is and altering the bytecode 
> only to put circular_buffer and udvm_memory_size as explicit labels):
> 
> "   at (64)
> 
>    :location_a                     pad (2)
>    :location_b                     pad (2)
>    :location_c                     pad (2)
>    pad (30)
> Any comments appreciated.  In the absence of comments by 3pm 
> GMT on Thurs, I will assume that the above is ok and submit 
> the draft accordingly.
> 
> Best regards,
> 
> Abbie
> 
> 
> > Perhaps a detailed commentary of the code would help to get the 
> > message across?
> > 
> > My suggestion:
> > 
> > locations taken up by the instruction opcode and operands are not 
> > modified.
> (processing 
> > of parameter $location_a), the value stored at location_a 
> is accessed 
> > using operand indirection, and the result of this operation 
> is stored 
> > at location_c. For correct operation, the value stored at 
> location_c 
> > in this example must be the address of circular_buffer. That is to 
> > say, the evaluation of indirection for a MULTILOAD operand must be 
> > performed after the memory updates caused by previous steps of the 
> > MULTILOAD execution."
> > 
> > > I don't think it does contradict section 9.2.2 - that's 
> the section 
> > > it's meant to clarify.  However, I can see the confusion so it 
> > > probably needs to be clarified more clearly!
> > > 
> > > (including its operands) itself" means the memory taken up by the 
> > > instruction and the 1-3 byte representations of its 
> parameters.  It 
> > > does not include any memory referred to by the parameters.  
> > > Consequently ':location_a' is not part of the instruction 
> and so the 
> > > instruction is not being overwritten.
> > > 
> > > Would the addition of the sentence 'The memory area that 
> must not be 
> > > modified by the execution is that between the byte of the 
> MULTILOAD 
> > > opcode and the final byte of the final operand.' add suitable 
> > > clarification?
> > > 
> > > Best regards,
> > > 
> > > Abbie
> > > 
> > >