[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua workshop: call for backup presentations.
- From: Asko Kauppi <askok@...>
- Date: Sat, 26 Aug 2006 00:48:14 +0300
I wouldn't emphasize the benchmarks at this point, really.
I'd want us to strive towards a system, where all number handling
stuff is in a specific .[ch] pair of files (which carries absolutely
nothing more). There wouldn't be any harm in doing this, to regular
Lua, right?
Let's call this lnum.[ch]
Then, one can have lnum_bcd.[ch], and simply using these in compile/
linkage shall create you a BCD variant of Lua.
Others would be:
lnum_int.[ch] Pure integers only
lnum_intopt.[ch] Integer optimized, int32|64 + float|double
lnum_complex.[ch] a + bi
...
Such, community provided files can be carried in the etc/ folder,
unless the Lua authors want to have them truly integrated.
Lua bytecode identification should possibly be extended, to somehow
identify the whole number scheme a precompiled block has. Current int/
float/double detection will fall short. This is easy to do, with a
list of 'magic codes' maintained by Lua authors:
LUA_NUM_FLOAT 0x1
LUA_NUM_DOUBLE 0x2
LUA_NUM_LONGDOUBLE 0x3
...
LUA_NUM_INT16 0x8
LUA_NUM_INT32 0x9
LUA_NUM_INT64 0xa
...
LUA_NUM_BCD 0x80
LUA_NUM_COMPLEX 0x90
...
MSB/LSB information would need to be separately stored.
-asko
Vijay Aswadhati kirjoitti 25.8.2006 kello 21.40:
On 8/25/06, Andy Start wrote:
I don't think decimal should be seen as a relic of the IBM
mainframe age.
It has desirable properties but is inefficient. We used to think of
interpreted languages as desirable/inefficient but in the age of
faster
processors, we have Lua and we are all the better off for it.
I agree. And I think it is a worthy subject for the round-table
discussion
at the workshop. A one number model goes well with the design of
Lua's one
native number type support. To make the discussion concrete some
benchmark
results could come in handy for the proponents and opponents. Hint,
hint!!
Cheers
Vijay Aswadhati