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

From: Pekka Pessi <[email-masked]>
Date: Mon, 06 Jun 2005 15:52:24 +0300

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?

>cristian: now, your MULTILOAD instruction is located at byte 0x80 
>and it's writing 4 shorts (8 bytes) starting at 0x40 up to 0x48;
>there is a "gap" of 56 bytes btw. the last address MULTILOAD is writing
>to and the location where MULTILOAD is loaded; so MULTILOAD is not
>overwriting itself. (it is NOT self-modifying)

That is correct.

...
>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.

However, the section 2.5 of torture-tests states:

   1.  The MULTILOAD instruction overwrites itself, any of its operands,
   or any memory addresses referenced by its operands (in which case
   decompression failure should occur).

This would imply that if a multiload included a reference operand,
the MULTILOAD should not overwrite the referenced address. 
However, the last MULTILOAD in the test indeed does overwrite the
address referenced by operand, (it copies 42 around twice).

So it looks like to me that the description of the test is in
error, and that the test description should be read, for example,
like this:

   1. The MULTILOAD instruction overwrites itself or any of its operands,
   in which case decompression failure should occur. 

   2. The memory references of MULTILOAD instruction operands are
   evaluated step-by-step rather than all at once before starting
   to copy data.

   3. The MULTILOAD instruction overwrites memory addresses referenced by
   its operands, in which case decompression failure must not occur.

Perhaps similar clarification should be added in the impl-guide,
too.

--Pekka

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Mon, 6 Jun 2005 16:01:52 +0200

>    decompression failure should occur).

cristian: sorry, must have overlooked this test... however if I look
again to the sigcomp rfc definition of MULTILOAD, more specifically 
to the following paragraph:

"Decompression failure occurs if the set of 2-byte words set by the
instruction would overlap the memory locations held by the
instruction (including its operands) itself, i.e., if the instruction
would be self-modifying." 

it is not clear to me that a MULTILOAD that writes at addresses
referenced by one of its operators should issue a Decompression failure.

now reusing a snippet from the code above:

:initialize_memory 
MULTILOAD (byte_copy_left, , 
    circular_buffer, udvm_memory_size, (f_bit|p_bit),
    $byte_copy_left)
:end_initialize_memory 

in my understanding of the rfc the only case when the MULTILOAD above
would cause a Decompression failure would be when it writes something at
an address greater than the value of the label initialize_memory and
lower than end_initialize_memory.

-- 
 _          | 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