Re: poll on luac

[Mike Pall <mikelu-0506@...>]

Hi,

Luiz Henrique de Figueiredo wrote:
> We're thinking of dropping the support for handling non-native byteorder
> when loading precompiled chunks. Would this be a disaster to you?

Since endianess is not the only portability concern, it's rather
pointless to leave it in (even if it only saves 10 lines). Either
go for full binary portability or only support a native loader
in the core. IMHO the latter is most appropriate for Lua.

A cross-compiler is needed in this case. Here's a list of
portability concerns that a cross-compiler needs to handle:

1. Endianess: swap on output as needed.

2. sizeof(size_t), affects huge string constants: check for overflow
   when downgrading.

3. sizeof(int), affects MAXARG_Bx and MAXARG_sBx: check for overflow
   when downgrading.

4. typeof(lua_Number): easy in C, but only when the host and the
   target follow the same FP standard; precision loss when upgrading
   (rare case); warn about non-integer numbers when downgrading to
   int32.

sizeof(Instruction) is no longer a concern, since 5.1 has better
64 bit portability (i.e. it should be 32 bit everywhere except
for (extinct) ILP64 platforms).

A cross-compiler only needs a special variant of ldump.c. This
could be made conditional (only activated for luac) to avoid
bloating the Lua core (and still be part of the standard
distribution).


Another possibility is to rewrite luac in pure Lua. However this
either needs a few more introspection capabilities (for functions
and the Lua VM in general -- needs to go into the core) or a
standard library that must be in sync with the core (could be
generated from lopcodes.* and is preferrably written in pure Lua).

The latter sounds much more attractive and would be of general
use for all kinds of code analysis and code generation tools.
It should provide a list of opcodes, opcode modes and a few
functions to split and merge instructions, instruction streams
and precompiled chunks.

Bye,
     Mike