Subject: [rohc] Sigcomp Torture Test: Stack Manipulation

From: [email-masked]
Date: Mon, 25 Nov 2002 21:19:37 -0600

Hi,
    I have doubt regarding the output value of stack manipulation test case. 

Initially, before start of UDVM, snapshot of UDVM buffer from address 64 to 72 is

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

Executing LOAD (stack_location, 64)
Name: 		byte_copy_left 	byte_copy_right		input_bit_order		stack_location		next_address
Address:	64		      66				68			70		72
Value:		0		      0				0			64		0

Executing PUSH (2)
Name: 		byte_copy_left 	byte_copy_right		input_bit_order		stack_location		next_address
Address:	64		      66				68			70		72
Value:		1(stack_fill) 	      2				0			64		0	

Executing PUSH ($64)
Name: 		byte_copy_left 	byte_copy_right		input_bit_order		stack_location		next_address
Address:	64		      66				68			70		72
Value:		2 (stack_fill)	      2				1			64		0	

Executing, PUSH (66)
Name: 		byte_copy_left 	byte_copy_right		input_bit_order		stack_location		next_address
Address:	64		      66				68			70		72
Value:		3		      2(stack_fill)			1			66		0	

Observations: contents of stack location register was changed. It's new value is 66. The stack_fill (stack_fill is described as per section 8.3 in sigcomp-07.txt) value is now 2, which means number of items in stack is 2. 

Now, we have 3 POP operations which inturn decreases the value of stack_fill. During the third POP operation we should get decompression failure as opposed to the OUTPUT described in the sigcomp torture draft (Because, the first 2 POP operations cause new stack_fill to be 0 )
  
  Please let me know if anyone experienced the same problem or any corrections in my interpretation of the draft.

thanks,
Narendra

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

---

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

hi Narendra,

from my implementation, the first pop gives :

Name:   byte_copy_left  byte_copy_right         input_bit_order 
stack_location          next_address
Address:                  64             66                     68 
             70              72
Value:          66                 1                    1 
     66              0

the second pop gives :

Name:   byte_copy_left  byte_copy_right         input_bit_order 
stack_location          next_address
Address:                  64             66                     68 
             70              72
Value:          66                 1                    1 
     66              0

as you can see, the stack fill has a value of 1 after 2 pops. i think the 
trick is that the value 1 from mem[68] is copied
to mem[66] at the second pop.

regards,
Kwang Mien

>Address:        64                    66                                68 
 >                     70              72
>Value:          0                     0                         0 
 >             0               0
>Address:        64                    66                                68 
 >                     70              72
>Value:          0                     0                         0 
 >             64              0
>Address:        64                    66                                68 
 >                     70              72
>Address:        64                    66                                68 
 >                     70              72
>Value:          2 
>(stack_fill)        2                         1                       64 
 >           0
>Address:        64                    66                                68 
 >                     70              72
>Observations: contents of stack location register was changed. It's new 
>value is 66. The stack_fill (stack_fill is described as per section 8.3 in 
>sigcomp-07.txt) value is now 2, which means number of items in stack is 2.
>
>Now, we have 3 POP operations which inturn decreases the value of 
>stack_fill. During the third POP operation we should get decompression 
>failure as opposed to the OUTPUT described in the sigcomp torture draft 
>(Because, the first 2 POP operations cause new stack_fill to be 0 )
>
>   Please let me know if anyone experienced the same problem or any 
> corrections in my interpretation of the draft.
>
>thanks,
>Narendra
>
>
>
>
>
>