Subject: RE: [rohc] SigComp torture tests

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 22 Apr 2005 17:30:55 +0100

Hi Pekka,

I've run this test and agree with its description and conclusions.  I'll
update it in the next version of the torture test draft.

Best regards,

Abbie

> -----Original Message-----
> From: Pekka Pessi [mailto:[email-masked]] 
> Sent: Monday, March 14, 2005 5:22 PM
> To: Surtees, Abigail
> Cc: 'Pekka Pessi'; [email-masked]; 'Herve Siegrist'
> Subject: Re: [rohc] SigComp torture tests
> 
> 
> Hi Abigail,
> 
> "Surtees, Abigail" <[email-masked]> writes:
> >I've run this torture test plus the other 2 you suggested for
> >torture-tests-00.txt with the following results:
> 
> >Use 3485 state:
> >	Agrees with the stated output and number of cycles :-)
> 
> >Bytecode state creation:
> 
> >	Message 2 does not work - the bytes given under 'Second 
> message' are
> >not the same as the ones given in the textual description 
> higher up.  The
> >message in the textual description is the one that references state
> >correctly.  I don't think there is any need for the messages 
> to be given
> >twice and there is a good description of what the messages 
> do before the
> >bytecode so I've suggested some alternative text below.
> 
> >	The output from the 2nd message I get is 0x4f4b 32 
> (rather than 31
> >at the end).  Is this correct (as far as I can see from the 
> mnemonic code,
> >it should be 32)?  (This means I agree with Herve.)
> 
> A copy and paste error, I'm sorry. My own test driver uses 4f 
> 4b 32, too.
> 
> >	Again for message 3, the last byte of output I get is 
> 32 rather than
> >31.  (And again, I agree with Herve.)
> 
> >	The number of cycles are the same as stated.
> 
> >	General comments:
> 
> >		Having worked out what this bytecode does, I think the
> >description is slightly misleading - the bytecode isn't 
> self-modifying as
> >the area containing bytecode is never overwritten during its 
> execution.  I
> >suggest removal of the words "self-modifying byte code," from the
> >description.
> 
> You are absolute right. I wrote the test case because some UDVM
> implementations had problems with my bytecode, one when the
> bytecode was modified, another when the bytecode state started
> before 128. The contributed torture test case does not test
> self-modification, only the second problematic case. 
> 
> Now I added a INPUT-BYTES modifying the OUTPUT() instruction,
> please see the modified UDVM assembly and messages below.
> 
> >		One addition to the test is that of switching 
> the LOAD and
> >first STATE-CREATE instructions.  This would then also check 
> that if the
> >area to be saved is modified after the STATE-CREATE request, 
> it still works.
> >What do you think?
> 
> That sounds great. 
> 
> >	Updated text for this test is given below.
> 
> Again...
> 
> --Pekka
> 
> 4.5  Bytecode state creation
> 
>    This section gives assembly code to test storing bytecode using
>    END-MESSAGE and later loading the bytecode using a partial state
>    identifier within the SigComp header.  The assembly code 
> is designed
>    so that it includes testing changing bytes to be stored after the
>    state create request, loading byte code in special memory areas and
>    correct initialization order of the UDVM.
>    1.  Four items of bytecode state are created.  The bytes 
> to be saved
>        change after the first state create request.  The 
> uploaded bytecode
>        is modified before execution.
>    2.  The bytecode is loaded using partial state identifier 
> and modified.
>    3.  The bytecode is loaded before 128 using partial state 
> identifier.
>    4.  The bytecode is loaded using partial state identifier.  Part of
>        the loaded memory is reserved area, which is overwritten after
>        loading the bytecode.
>    5.  The byte loading fails because partial state identifier is too
>        short.
> 
> 	at (30)
> :save_area1
> 	set (saved_instr1, (save_area1 + (code_start2 - start_saved)))
> 
> 	at (80)
> :save_area2
> 	set (saved_instr2, (save_area2 + (code_start2 - start_saved)))
> 
> 	at (128)
> :code_start
> 
> 	COPY (start_saved, saved_len, save_area1)
> 	STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10)
> 
> 	set (modify1, (save_area1 + 5))
> 	LOAD (modify1, 0x1e03)
> 
> 	COPY (start_saved, saved_len, save_area2)
> 	STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10)
> 	STATE-CREATE (saved_len, save_area2, saved_instr2, 12, 10)
> 	JUMP (modify)
> 
> :ok1	byte (0x4f, 0x4b, 0x31)
> 
> :modify
> 	INPUT-BYTES (1, (after_output - 1), !)
> 	OUTPUT (ok1, 3)
> :after_output
> 
> 	; Save from ok1 to the opcode of END-MESSAGE 
> 	set (modify_len, ((after_output + 1) - ok1))
> 
> 	END-MESSAGE (0, 0, modify_len, ok1, modify, 6, 10)
> 	
> 	set (saved_len, (end_saved - start_saved))
> 
> :start_saved
> 	byte (0x4f, 0x4b, 0x32)
> :code_start2
> 	; OUTPUT (save_area2, 3)
> 	byte (0x22, 0xa0, 0x50, 0x03)
> 	; END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
> 	byte (0x23)
> :end_saved
> 
> 
>    The expected outputs and cycle usages are:
> 
>    Message              Output                  Cycles
>    1                    0x4f4b                  67
>    1                    0x4f4b 31               7
>    2                    0x4f4b 32               5
>    3                    0x0000 32               5
>    4                    None                    Decompression failure
> 
>    First message:
> 
>    0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008
>    0xa050 a053 140a 2008 a050 a053 0c0a 1605 4f4b 311c 01a0 b39f 5522
>    0xa0a7 0323 0000 0ea0 a7a0 aa06 0a4f 4b32 22a0 5003 2302
> 
>    Second message:
> 
>    0xf953 e97f 4afd d203
> 
>    Third message:
> 
>    0xfb24 63cd ff5c f8c7 6df6 a289 ff
> 
>    Fourth message:
> 
>    0xf95b 4b43 d567 83
> 
>    Fifth message:
>    
>    0xf9de 8126 1199 1f"
> 

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