Re: Extending Lua for multiple light userdata types

[Rena <hyperhacker@...>]

On Tue, Nov 13, 2012 at 11:00 AM, Xavier Wang <weasley.wx@gmail.com> wrote:
> what about using luaFFI and int64_t? is that slow?
>
> 2012/11/13 Rena <hyperhacker@gmail.com>:
>> On Tue, Nov 13, 2012 at 10:42 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>>> 2012/11/13 Rena <hyperhacker@gmail.com>:
>>>
>>>> Recently I was thinking about how you might add a 64-bit integer type to Lua.
>>>
>>> This is only a pressing question if you need IEEE floats and 64-bit integers
>>> in the same program, otherwise you can build Lua with 64-bit integers
>>> as your `number`.
>>>
>>
>> True, but I really prefer to leave recompiling Lua as a last resort. I
>> like to write my code as much in pure Lua as possible, and having it
>> depend on a custom version of Lua would bother me. Especially, when
>> you have a custom Lua, you often need to recompile all the C libraries
>> you use as well to work with it.
>>
>> There's a patch on the wiki somewhere that adds an "integer" type and
>> a bunch of bit operators. It's fairly invasive and has a few nasty
>> bugs, but it shows how new primitive types can be added. IIRC the VM
>> defines 9 of them before the "heavier" types (that need to be
>> allocated and collected), so if you allowed for 7 custom types, that
>> makes for a nice round number, and should probably be plenty. (But I
>> wonder how the VM encodes type information; maybe there's room for
>> many more?)
>>
>> --
>> Sent from my Game Boy.
>>
>
>
>
> --
> regards,
> Xavier Wang.
>

I'm not sure. I haven't looked at how FFI is implemented. It seems
like it would have more overhead than native primitive types, though.

-- 
Sent from my Game Boy.