Re: NaN trick

[Michael Rose <michael.h.rose@...>]

Am 06.07.2011 18:24, schrieb Peter Cawley:
> On Wed, Jul 6, 2011 at 4:57 PM, Michael Rose <michael.h.rose@web.de> wrote:
>> I think it should also work on current AMD 64bit platforms. This would reduce a Lua value
>> from 16 bytes down to 8 bytes on the Lua stack and within tables!
> 
> Though you then need to get slightly more creative about encoding the
> type. A double has 52 bits of mantissa; with 48 taken for a
> pointer-sized value, and 1 taken to ensure a quiet NaN, you only have
> 3 bits left to encode the type. If you borrow the sign bit as well,
> then you have 4 bits. For reference, the current implementation in 5.2
> beta uses 6 bits for encoding type.
> 

Of course You have to compress the type information a bit to be successful.

NaN's to be abused are restricted to be
  "FFF8 0000 0000 0000" + X or
  "7FF8 0000 0000 0000" + X with X > 0
according to the IEEE specs.

The topmost sign bit 63 "s" can be used, as well as bits 48-50 "ttt"
Bit 47 could be used for all GC data, because they are never system
pointers.
All immediate values which use only 32 data bits could
also be combined under one major type number, because they
can be distinguished by minor type numbers in the bit range
32-47.
If allocators could be restricted to some alignment, also bits 0-2
are useable, but if generality is of more concern (especially to not
restrict custom allocators), these bits are not available.

s ttt
0 000   LUA_TNUMBER
0 001   LUA_TNIL
0 010   LUA_TBOOLEAN
0 011   LUA_TLIGHTUSERDATA
1 000   LUA_TSTRING
1 001   LUA_TTABLE
1 100   LUA_TFUNCTION    LUA_TLCL
1 101   LUA_TFUNCTION    LUA_TLCF
1 110   LUA_TFUNCTION    LUA_TCCL

Some free combinations 0100-0111, 1010-1011 are still available.
The sign bit indicates collectable data. In case of functions,
bits 48-49 codes the variant tag.
LUA_TNUMBER has coding 0 000, because then all other
data represent quiet NaN's, which are free to be abused
as indicated in the specification.

Regards,

Michael Rose