lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2009/12/9 Mike Pall <>:
> Peter Cawley wrote:
>> On Wed, Dec 9, 2009 at 11:06 AM, Mike Pall <> wrote:
>> >
>> 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).