Subject: RE: Clarification in torture-tests and impl-guide (Re: [rohc] MUL TILOAD operands)

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 7 Jun 2005 17:50:58 +0100

Hi Pekka, Cristian,

My answer yesterday to this discussion was about clarifications needed in the torture tests draft.  It also seems that the RFC is not as clear as it could be and so there should also be an update to the implementer's guide is also needed.

Let's look in more detail at Pekka's example below:

> Cristian CONSTANTIN <[email-masked]> writes:
> >> at (64) 
> 
> >> :byte_copy_left                 pad (2) 
> >> :byte_copy_right                pad (2) 
> >> :input_bit_order                pad (2)
> >> set (f_bit, 4)
> >> set (h_bit, 2)
> >> set (p_bit, 1)
> >> :decompressed_pointer           pad (2) 
> 
> >> align (64)
> 
> >> :initialize_memory 
> 
> >> MULTILOAD (byte_copy_left, , 
> >> 	circular_buffer, udvm_memory_size, (f_bit|p_bit), 
> $byte_copy_left)
> 
> >> Is it supposed to fail, or not? If not, what is the expected value
> >> of $decompressed_pointer, circular_buffer or 0?
> 
> ...
> >I suppose that the value is must to be circular_buffer.
> >(this is at least how I understand/interpret the whole stuff).
> 
> Yes, that is my undestanding, too. However, MULTILOAD has 
> multitype operands
> that can be reference or indirect operands, like the last 
> operand above. So,
> the point is the conceptual model of decoding the 
> instructions first and
> executing them afterwards. Does the conceptual model stipulate that we
> resolve the indirection in the instruction decoding phase, or 
> does it happen
> in the execution phase? I though that the latter was the intention.

For most of the instructions, the conceptual model is decode all parameters then execute the instruction.
MULTILOAD seems to be the oddball.  The RFC states that the restriction against self modifying code "makes it simpler to implement MULTILOAD step-by-step instead of having to decode all operands before being able to copy data, as is implied by the conceptual model of instruction execution."
Incremental execution of the MULTILOAD instruction, leads in the example above to the answer circular_buffer.  Execution has to be consistent, therefore non-incremental execution must lead to the same answer - i.e. even if the operands are decoded, any indirection has to be resolved in the execution phase. 

This is not explicitly stated in the RFC and so I think a comment to that effect should be put in the implementer's guide.

How about the following:

"MULTILOAD

The MULTILOAD instruction is explicitly not allowed to be self modifying in order to make step-by-step implementation simpler.  Therefore, any other implementation technique (e.g. decode all operands then execute, which is the model of all other instructions) must yield the same result as a step-by-step implementation would.  That is, if there is any indirection of parameters, the indirection must be done at execution time.  For example:

at (64) 
 
:location_a 	              pad (2) 
:location_b                     pad (2) 
:decompressed_pointer           pad (2) 

at (64)

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

once the MULTILOAD has been executed, decompressed pointer must contain circular_buffer."

Any comments?

Best regards,

Abbie

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Wed, 8 Jun 2005 15:53:52 +0200

> My answer yesterday to this discussion was about clarifications needed in the torture tests draft.  It also seems that the RFC is not as clear as it could be and so there should also be an update t…

cristian: what I find really interesting is that a collegue of mine,
when asked, interpreted the RFC def. of the MULTILOAD in the sense that
was suggested in the torture-tests:

"...or any memory addresses referenced by its operands (in which case
   decompression failure should occur)."

without even looking at the torture tests. so I suppose the extra
example, clarification is need.

-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 08 Jun 2005 16:09:39 +0300

"Surtees, Abigail" <[email-masked]> writes:
>My answer yesterday to this discussion was about clarifications
>needed in the torture tests draft. It also seems that the RFC is
>not as clear as it could be and so there should also be an update
>to the implementer's guide is also needed.

>For most of the instructions, the conceptual model is decode all
>parameters then execute the instruction. MULTILOAD seems to be
>the oddball. The RFC states that the restriction against self
>modifying code "makes it simpler to implement MULTILOAD
>step-by-step instead of having to decode all operands before
>being able to copy data, as is implied by the conceptual model of
>instruction execution." Incremental execution of the MULTILOAD
>instruction, leads in the example above to the answer
>circular_buffer. Execution has to be consistent, therefore
>non-incremental execution must lead to the same answer - i.e. 
>even if the operands are decoded, any indirection has to be
>resolved in the execution phase.

MULTILOAD is an exception in the sense that it can make a
difference between step-by-step and decode-at-once style of
execution. On the other hand, I think that the decode-at-once
style implementations do decoding before execution because they
try to save or cache the results of the instruction and operand
decode phase. They can reuse already decoded instruction if the
instruction has not been modified. For obvious reasons the
reference operands are resolved at the execution time even if
there is a pre-decoded instruction available.

>This is not explicitly stated in the RFC and so I think a comment
>to that effect should be put in the implementer's guide.

>The MULTILOAD instruction is explicitly not allowed to be self
>modifying in order to make step-by-step implementation simpler. 
>Therefore, any other implementation technique (e.g. decode all
>operands then execute, which is the model of all other
>instructions) must yield the same result as a step-by-step
>implementation would. That is, if there is any indirection of
>parameters, the indirection must be done at execution time. For
>example:

>contain circular_buffer."

Text looks mostly fine to me. Replace "decompressed pointer" with
"decompressed_pointer", or both with "location_c"? The latter
at(64) should be align(64), I think.

--Pekka