[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Re: [ANN] LuaJIT x64 port sponsorship program
- From: Jerome Vuarand <jerome.vuarand@...>
- Date: Wed, 9 Dec 2009 15:06:28 +0100
2009/12/9 Mike Pall <firstname.lastname@example.org>:
> Peter Cawley wrote:
>> On Wed, Dec 9, 2009 at 11:06 AM, Mike Pall <email@example.com> 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).
> 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).