Subject: [rohc] questions on Stack Manipulation test

From: Chan Kwang Mien <[email-masked]>
Date: Tue, 26 Nov 2002 17:08:19 +0800

hi,

i have 2 questions on the 3.13 Stack Manipulation test in the SigComp 
torture tests.

a) i could only get the expected output when the instruction LOAD (383, 26)
is changed to LOAD (383,25). does anyone face the same problem ?

b) i dont seem to get the total UDVM cycles as stated in the draft which is
39. i have 38 cycles. my understanding is

Instruction Flow                               UDVM cycle

Load 					1
3 Pushes 				3
1 Output with output length 		9
3 Pops				3
1 Output with output length 		9	
Jump					1
Load					1
Subtract				1
Call					1
Call					1	
Load					1	
Load					1	
Multiload				4
Return				1
End-Message				1
		
				Total :  38

Any help is much appreciated.

regards,
Kwang Mien

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

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 26 Nov 2002 11:16:33 -0000

Hi Kwang Mien,

The stack manipulation torture test is living up to its name! The
catch is that there's a "hidden" RETURN instruction not present in
the UDVM assembly code, but which is instead created on-the-fly by
the stack manipulation instructions themselves.

I'll try to explain this further by describing the last few steps of
the test. The situation after executing the MULTILOAD is as follows:

stack_location = 383          stack_fill = 26

Address:   432        433        434        435        436        437

Value:       0          1        192          1        128          0

The next instruction is a RETURN, which decreases stack_fill to 25 and
then retrieves the 2-byte value from Address 383 + 2 * 25 + 2 = 435,
which from the above diagram is the value 384. The UDVM then continues
program execution at Address 384.

This is where things start to get nasty! Address 384 is the least
significant byte of stack_fill (which currently contains the value 25).
From Figure 11 of the SigComp draft this is the bytecode value for a
RETURN instruction, so the UDVM decreases stack_fill to 24 and then
retrieves the 2-byte value from Address 383 + 2 * 24 + 2 = 433. From
the previous diagram this is the value 448, so the UDVM jumps to the
END-MESSAGE instruction and then terminates.

Your suggestion to change LOAD (383, 26) to LOAD (383, 25) also gives
the correct output on our implementation, but misses out the hidden
RETURN instruction and thus uses one fewer UDVM cycles than expected.

Let me know if this helps!

Regards,

Richard

> -----Original Message-----
> From: Chan Kwang Mien [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 9:08 AM
> To: [email-masked]
> Subject: [rohc] questions on Stack Manipulation test
> 
> 
> hi,
>

---

From: [email-masked]
Date: Tue, 26 Nov 2002 11:13:42 -0600

Hello,
  I have one more question regarding the stack manipulation test case. After, the PUSH and POP operations, register values are

Name:   byte_copy_left  byte_copy_right  input_bit_order  stack_location next_address
Address:        64             66             68              70              72
Value:          0x42		0x0		    0x1		   0x1		0x0

SO, stack_location = 1 (value at address 70)
stack fill value = 2-byte integer value at address 1 --> lsb of udvm_memory_size and msb of cycles_per_bit.

Because at address 0, we have udvm_memory_size and at address 2, we have cycles_per_bit. 

I get incorrect operation because of the new stack_fill value (taken from address 1). 

Any suggestions is appreciatd.

-Narendra

---

From: Chan Kwang Mien <[email-masked]>
Date: Wed, 27 Nov 2002 08:40:19 +0800

hi Narenda,

in this case, the stack location should be 0x100. the stackfill value is 
the value at memory location 0x100.
after the push and pop, if you trace through, the stackfill has a new value 
i.e. 26 caused by the
instruction LOAD( 383, 26).

regards,
kwang mien

>Hello,
>   I have one more question regarding the stack manipulation test case. 
> After, the PUSH and POP operations, register values are
>
>Address:        64             66             68              70 
 >   72
>stack fill value = 2-byte integer value at address 1 --> lsb of 
>udvm_memory_size and msb of cycles_per_bit.
>

---

From: Chan Kwang Mien <[email-masked]>
Date: Wed, 27 Nov 2002 08:44:58 +0800

hi Richard,

thanks for your help. finally obtained the results of the stack 
manipulation test.
found a bug in my program, i.e i did not reduce stackfill by 1 when 'return'.
hence, program jump to a 'switch' instruction instead.

regards,
kwang mien

---

From: [email-masked]
Date: Wed, 27 Nov 2002 14:58:43 -0600

Hi Chan,
  Thank you for your emails. I'm getting the right output but the actual problem starts with the first CALL instruction because of the stack_fill value. I'm giving a trace of the instruction till the first CALL so that you could compare with your trace and pinpoint where exactly i'm  defering. 

Initially, this is the snapshot.
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       0      0           0    0        0

Instruction: LOAD
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       0      0           0    64        0

Instruction: PUSH (2)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       1      2           0    64        0

Instruction: PUSH ($64)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       2      2           1    64        0

Instruction: PUSH (66)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       2      2           1    64        0

Instruction: PUSH (66)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :       3      2           1    66        0

Instruction : OUTPUT(64, 8)
              0x0003, 0x0002, 0x0001, 0x0042  (according to the draft at this point)

Instruction: POP (64)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :      66      1           1    66        0

Instruction: POP ($stack_location)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :      66      1           1    66        0

Instruction: POP (stack_location)
Name:      bcLeft    bcRight	  ibo  stLoc   n_addr
Address:     64	   66		  68	  70       72
Value :      66      0           1    1        0

INSTRUCTION : OUTPUT (64, 8)
		0x0042  0x0000 0x0001 0x0001  (accoring to draft till this point)

So, the total output is correct at this point. Now, after the two load instructions, we have CALL (address_b).

stack_location points to address 1 and so the stack_fill value is lsb of udvm memory size and msb
of sigcomp version. UDVM memory size is 1724 (2048 - 324). New stack fill value = 0xbc00 which 
is beyond UDVM memory. 

thanks,
Narendra

-----Original Message-----
From: ext Chan Kwang Mien [mailto:[email-masked]]
Sent: 26 November, 2002 06:40 PM
To: Chaparala Narendra (EXT-NRC/Dallas); [email-masked]
Subject: RE: [rohc] questions on Stack Manipulation test

hi Narenda,

regards,
kwang mien

---

From: Chan Kwang Mien <[email-masked]>
Date: Thu, 28 Nov 2002 11:39:05 +0800

hi Narenda,

now i understand your problem. pls ignore my previous mail. in my
testing, the memory address[0] always contain the value 2048.

i m not sure if we need to update the value in memory address[0]
real time, i.e. the remaining memory available. my understanding
is that once the remote compressor is aware of the total UDVM memory
size, the compressor will have to monitor the availability of the
UDVM memory.

regards,
Kwang Mien

>Hi Chan,
>   Thank you for your emails. I'm getting the right output but the actual 
> problem starts with the first CALL instruction because of the stack_fill 
> value. I'm giving a trace of the instruction till the first CALL so that 
> you could compare with your trace and pinpoint where exactly i'm  defering.
>

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 28 Nov 2002 15:57:54 -0000

> testing, the memory address[0] always contain the value 2048.

Hi,

A slight drawback of the current stack manipulation test is that it
might need more UDVM memory than has been allocated (which could
lead to a decompression failure if the test tries to write beyond
the end of the available memory).

It would be better if all tests could run using 1024 bytes or less,
so that they can be used even when the UDVM has the minimum
possible amount of memory available. I'll look into fixing this
for the next version of the torture tests - in the meantime giving
the UDVM 2048 bytes of memory should allow the stack manipulation
test to run OK.

> size, the compressor will have to monitor the availability of the

The UDVM memory size in Address 0 is set when the UDVM is initialised,
and is not subsequently updated while the bytecode is running.

Regards,

Richard