Re: NaN trick

[Patrick Donnelly <batrick@...>]

On Thu, Jul 7, 2011 at 12:54 AM, Miles Bader <miles@gnu.org> wrote:
> Peter Cawley <lua@corsix.org> writes:
>>> 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.
>
> The way other systems seem to do this, is to divide types into "true
> immediates", and "pointer + language heap obj".
>
> The former must have their tag uniquely encoded using only the bits
> available in immediate values, but the latter can have extra tag
> information in the header of the "language heap obj" pointed to by the
> pointer (and of course gc flags etc can also be stored there).
>
> For Lua, there seem to be 6 "true immediate" types:  number, nil,
> boolean, lightuserdata, and lightcfunction (anything else?).  So,
> adding a 7th immediate tag for the "lua_heap_object" case (which
> handles string, table, function, userdata, and thread types), that
> would seem to require only 3 tag bits in immediates...
>
> [nil and boolean could be combined using other bits in the immediate
> to distinguish them, meaning 6 immediate tags are used, leaving 2 for
> future use...]

There are other types as well: LUA_TPROTO, LUA_TUPVAL, LUA_TDEADKEY
(see lobject.h). The latter would be an immediate value I would think.

-- 
- Patrick Donnelly