Subject: RE: [rohc] questions on Stack Manipulation test

From: [email-masked]
Date: Mon, 2 Dec 2002 16:46:09 -0600

Hi Kwang Mein,
  memory address[0] should contain udvm memory size rather than decompression memory size. 2048, the default size of sigcomp is the decompression memory size. UDVM memory size in case for UDP is 2048 - size of sigcomp message. The size of sigcomp message for stack manipulation torture test case is 324 bytes and hence udvm memory size = 2048 - 324 = 1724 (0x6bc). This is the value that address 0 contains before executing the first instruction. 
  my interpretation is from section 3.3.1 of sigcomp-07 draft. Please correct me if my interpretation is correct.

-Narendra

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

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.
>
>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,
>
>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
> >
> >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
> >
> >
> >
> >_______________________________________________
> >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: [email-masked]
Date: Tue, 3 Dec 2002 11:16:23 -0600

Richard,
   stack manipulation torture test case depends upon the value of udvm memory size, stored at address 0. Also, the udvm memory size will never be 2048 as 2048 refers to decompression memory size rather than udvm memory size. In case of UDP, udvm memory size will be 2048 - sizeof (sigcomp message) and in TCP case, decompression_memory_size/2. 
   I'm having problems in UDP case with UDVM memory size. byte code size of stack test is 324 bytes and so udvm memory size is 1724 and at address 0 0x6bc is stored. In the current test case, after PUSH and POP operations, the value at stack_location is 1 and so when we have a CALL operation, stack_fill is the value at address 1, which is going to be 0xbc00 and obviously out of udvm memory address. 
  Successful execution of the test case depends upon the udvm memory size at address 0. 

-Narendra

-----Original Message-----
From: ext Price, Richard [mailto:[email-masked]]
Sent: 28 November, 2002 09:58 AM
To: 'Chan Kwang Mien'; Chaparala Narendra (EXT-NRC/Dallas);
[email-masked]

> 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

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 4 Dec 2002 16:53:20 -0000

>    stack manipulation torture test case depends upon the 
> value of udvm memory size, stored at address 0. Also, the 
> udvm memory size will never be 2048 as 2048 refers to 
> decompression memory size rather than udvm memory size. In 
> case of UDP, udvm memory size will be 2048 - sizeof (sigcomp 
> message) and in TCP case, decompression_memory_size/2. 

Hi,

A udvm_memory_size of 2048 is valid in the case of TCP as it's
possible to set the decompression_memory_size to 4096.

Alternatively, why not just set the udvm_memory_size to the
maximum possible value of 64K? This is always a valid memory
size over both UDP and TCP, and will ensure that there's more
than enough memory for the stack manipulation test to run.

Regards,

Richard