Re: Re: [ANN] LuaJIT x64 port sponsorship program

[Jerome Vuarand <jerome.vuarand@...>]

2009/12/9 Mike Pall <mikelu-0912@mike.de>:
> Peter Cawley wrote:
>> On Wed, Dec 9, 2009 at 11:06 AM, Mike Pall <mikelu-0912@mike.de> wrote:
>> > http://lua-users.org/lists/lua-l/2009-08/msg00202.html
>>
>> What does this mean for light userdata? Can you only give LuaJit2
>> light userdata which live in the lower 4GB, or does it transparently
>> box them in a special type of full userdata?
>
> You can pass it any pointer value that is legal on x64 in
> user-mode under the currently supported 48 bit memory model. In
> practice this means it's accepted by lua_pushlightuserdata() if
> the highest 16 bits are zero (user-mode pointers can only point to
> addresses 0 .. 2^47-1).
>
> That's why I said 'GC object' pointers are 32 bit. Lightuserdata
> is not a GC object and not boxed either. See lj_obj.h:
>
> Internal object tags:
>
> Internal tags overlap the MSW of a number object (must be a double).
> Interpreted as a double these are special NaNs. The FPU only generates
> one type of NaN (0xfff8_0000_0000_0000). So MSWs > 0xfff80000 are available
> for use as internal tags. Small negative numbers are used to shorten the
> encoding of type comparisons (reg/mem against sign-ext. 8 bit immediate).
>
>                 ---MSW---.---LSW---
> primitive types |  itype  |         |
> lightuserdata   |  itype  |  void * |  (32 bit platforms)
> lightuserdata   |fffc|    void *    |  (64 bit platforms, 48 bit pointers)
> GC objects      |  itype  |  GCRef  |
> number           -------double------

Does that mean that C modules that use light userdata to store size_t
integers (for example for bitfields) will have the upper 16bits
clamped ? For the moment I'm mostly concerned by the win32 API, which
uses the UINT_PTR type quite often. However in the partial bindings I
have so far all enum and bitfield types are 32bits (mostly DWORD).