Documenting the P2 varint format (read by RFVAR / RFVARS instructions)

CongaConga Posts: 44
It's not urgent, but I think it's worth doing.

'varint' = Varying-length Integer, or Variable-length Integer.

This is my current understanding of the format implemented by Chip (may be wrong).

Unsigned varint (RFVAR):

0xxx xxxx -> 0xxx xxxx (byte value less than 128)

1xxx xxxx 0yyy yyyy -> 00xx xxxx xyyy yyyy ? or 00yy yyyy yxxx xxxx

1xxx xxxx 1yyy yyyy 0zzz zzzz

1xxx xxxx 1yyy yyyy 1zzz zzzz vvvv vvvv

Signed varint (RFVARS):

0sxx xxxx -> ssxx xxxx

Where is the sign bit in the following?

1xxx xxxx 0yyy yyyy

1xxx xxxx 1yyy yyyy 0zzz zzzz

1xxx xxxx 1yyy yyyy 1zzz zzzz vvvv vvvv

Comments

  • 13 Comments sorted by Date Added Votes
  • cgraceycgracey Posts: 8,297
    edited May 5 Vote Up0Vote Down
    RFVAR reads from 1 to 4 bytes, lower bytes first, depending on the MSB's it sees in the coming byte sequence:
    %0aaaaaaa                                    -->                             %aaaaaaa
    %1aaaaaaa, %0bbbbbbb                         -->                     %bbbbbb_baaaaaaa
    %1aaaaaaa, %1bbbbbbb, %0ccccccc              -->             %ccccc_ccbbbbbb_baaaaaaa
    %1aaaaaaa, %1bbbbbbb, %1ccccccc, %dddddddd   -->    %ddddd_dddccccc_ccbbbbbb_baaaaaaa
    

    In the case of RFVARS, the value is sign-extended to 32 bits from the MSB of the data.

    For both RFVAR and RFVARS, C = MSB of the data and Z = data is zero.

    These instructions take two clocks.
  • RaymanRayman Posts: 8,326
    Wonder if it'd be more useful to have C and Z give you a 2-bit count of the number of bytes read...
    Prop Info and Apps: http://www.rayslogic.com/
  • You can always do a GETPTR to find out where you are.
  • RaymanRayman Posts: 8,326
    edited May 7 Vote Up0Vote Down
    I'm guessing you must be encoding the number of bytes needed into the first byte, right?

    I was just thinking that this might be useful as a simple way of compressing data, maybe something like RLE...

    I guess using a couple bytes in the first byte to say how many bytes in the packet is OK.

    But, would be faster if was transferred to C and Z flags...
    Prop Info and Apps: http://www.rayslogic.com/
  • Look at the diagram I made above. It's the MSB of the byte(s) that says if there's more data, or not.
  • RaymanRayman Posts: 8,326
    Yes, the encoder would set those bits...

    But, the decoder wouldn't know, right?
    Prop Info and Apps: http://www.rayslogic.com/
  • cgraceycgracey Posts: 8,297
    edited May 7 Vote Up0Vote Down
    The data tells the RFVAR circuit how much of it to grab, byte by byte.
  • cgraceycgracey Posts: 8,297
    edited May 7 Vote Up0Vote Down
    This is for quickly reading byte-efficient values from memory in a compose-once/read-many format. It's really great for bytecode interpreters.
  • RaymanRayman Posts: 8,326
    That's fine. I was just thinking about using this to compress a simple image.
    Maybe 4-byte data would be a 24-bit color value and 1-byte data would be a count of how many pixels to paint with that color. Similar to RLE encoding...
    Prop Info and Apps: http://www.rayslogic.com/
  • Thinking about the RFVAR instruction you could complement it with a MAKEVAR instruction.
    wire [28:0] makevar = {s[28,21],
    			|s[28:21],
    			s[20,14],
    			|s[28,14]],
    			s[13:7],
    			|s[28:7],
    			s[6:0]};
    
    For example
    	makevar	myvar		'make variable length value
    
    	topone	adj,myvar	'get magnitude
    	shr	adj,#3
    	add	adj,#1		'= number of bytes
    
    	rep	@.loop,adj	'save new varaiable length value
    	wrbyte	myvar,ptra++
    	shr	myvar,#8
    .loop
    

    or even better a WVLONG instruction as well that works similar to WMLONG except only bytes below the highest zero byte are written.
    	makevar	myvar		'make variable length value
    	wvlong	myvar,ptra	'write new var (1-4 bytes)
    
    This way the values are no longer "compose once" type.

    Ducks for cover.....
    Melbourne, Australia
  • MJBMJB Posts: 966
    edited May 7 Vote Up0Vote Down
    cgracey wrote: »
    RFVAR reads from 1 to 4 bytes, lower bytes first, depending on the MSB's it sees in the coming byte sequence:
    %0aaaaaaa                                    -->                             %aaaaaaa
    %1aaaaaaa, %0bbbbbbb                         -->                     %bbbbbb_baaaaaaa
    %1aaaaaaa, %1bbbbbbb, %0ccccccc              -->             %ccccc_ccbbbbbb_baaaaaaa
    %1aaaaaaa, %1bbbbbbb, %1ccccccc, %dddddddd   -->    %ddddd_dddccccc_ccbbbbbb_baaaaaaa
    

    In the case of RFVARS, the value is sign-extended to 32 bits from the MSB of the data.

    For both RFVAR and RFVARS, C = MSB of the data and Z = data is zero.

    These instructions take two clocks.

    when seeing this (and I did not follow all the discussion ...)
    I wonder if there is a inverse WFVAR, which takes a long and write it so it can be read with RFVAR(S)?
    Doing this manually is long.
    Or will this be done by the assembler / compiler only and not used in runtime?
    This would be nice for some data compression/uncompression ...

    EDIT: OZ - you were faster ;-) ... but obviously the idea is in the 'air'
    http://www.smmu.info (german) Source-Measure-Multiplex-Unit = professional test system for electronic components, sensors, assemblies
    Tachyon code and documentation snippets from Tachyon thread
  • I think it might be a waste to make a WFVAR, since it may not have much practical use (data would always have to be read sequentially and from the beginning), plus it would require a 32-bit negation circuit for WFVARS. Then, there's the problem that not all data would even be representable. RFVAR{S} is really just for run-time stuff.
  • evanhevanh Posts: 4,372
    edited May 7 Vote Up0Vote Down
    Rayman wrote: »
    Maybe 4-byte data would be a 24-bit color value and 1-byte data would be a count of how many pixels to paint with that color. Similar to RLE encoding...
    I'd recommend using something like the Amiga's HAM mode. It was notably superior because it assumed constant variation in the tone. It's weak point was with the RGB colour space it used, which meant colourised artefacting ...
    The Prisoner's Dilemma, in english - "Selfishness beats altruism within groups. Altruistic groups beat selfish groups." - Quoted part from 2007, D.S Wilson/E.O Wilson.
Sign In or Register to comment.