On Jun 20, 2006, at 10:47 PM, Petr Gladkikh wrote:
> switch (leading-byte) {
> 'I': parse_integer // returns integer
> 'i': parse_var_integer // returns integer
> 'R': parse_reference // returns back reference
> 'r': parse_var_reference // returns back reference
> }
>
> Where procedures whose names starting with "parse_var_" interpret next
> byte as containing byte-length and portion of bits. In order to reduce
> number of bit-shifts that portion of bits should represent higher
> ones.
I'm not sure I understand how that would help. The current proposal
has the number of bytes needed encoded in the first byte:
0x01 - 8-bit integer
0x02 - 16-bit integer
'I' - 32-bit integer
We could add a 0x03 - 24-bit integer, but I'm not sure how important
those numbers are.
So the overhead is a constant single byte plus the number of bytes
needed to write the data.
We could combine the ideas into something like:
0x10 - 0x1f - 12-bit integer
That would allow integers from -2048 to 2047 to be encoded in only
two bytes instead of three. Is that more of what you're thinking?
-- Scott
> Respective parse procedure for variable length integer values would
> look like
>
> ILEN = 4 // length of "normalized" integer (4 for int or 8 for long)
> result = (byte array of length that can be interpreted as big-endian
> long or integer)
>
> b = read_next
> len = b >> 5 // get length in bytes
> result[0] = (b & 0x10) << 3 // store sign
> result[ILEN - len - 1] = b & 0x0f // store higher bits
> for i = (ILEN - len) to ILEN
> {
> result[i] = read_next
> }
> return result
>
> --
> Petr
>
Received on Thu 22 Jun 2006 08:44:10 -0700
This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 20:16:41 PDT