Re: poll on luac

[Luiz Henrique de Figueiredo <lhf@...>]

Thank you all for your replies. Here are a few comments on them.

>I would suggest dropping the handling support, but keeping the header
>field necessary to identify the byte ordering.

That was my plan.

>Am I correct in saying that cross-compiling is currently not
>supported with a stock compile of luac?

Yes, luac does not support cross-compiling. It seems that cross-compiling
is much more desirable than simple byte swapping magic. However, it would
complicate matters quite a bit to do it right. The goal of precompilation
is fast loading and avoidance of the parser modules (for embedded systems).
We'd like to keep it this way.

>Would it be possible to produce a byte-order swizzling tool that could be
>run outside of the normal load process?

Yes, that'd be possible and easy by simply using a different lundump.c.
Actually, I think that this is the way to go: lundump.c is simple enough
that it can be customized because it only relies on a few "primitive"
functions that load basic types. There is no need to fiddle with the
high-level code that knows about the structure of precompiled chunks.
While catering for every possible combination of compilation/execution
platforms would be a nightmare, it should be easy to do whatever is needed
for any given pair.

On the other hand, I'll probably leave the current byte-swapping as a
build option (which will be off by default).

>what about a parameter to luac that tells it what kind of byte-order code to
>produce?

Like I said before, I think the easiest way is to change the loader,
not the dumper. However, it's probably best to change the dumper for
cross-compilation because then the loader can proceed at full speed.

The dumper has a similar structure of primitive functions and so is easy
to change.

While I do not see out-of-the-box support for cross-compilation as a
desirable feature of Lua, I do hope that specialized dumper/loader modules
are written by the community and made available to the community. I'm
willing to help, say by answering questions and providing code snippets.

>For that matter, how tenable would it be to write code that could update
>from Lua 5.0 bytecodes to Lua 5.1 bytecodes (using that as an example of a
>minor architectural revision to the virtual machine)?

Oh, that's a whole different story... But it shouldn't be too hard.
I guess the only problems would be the removal of OP_TFORPREP and the
fact that the numerical codes of the opcodes has changed because new
instructions were inserted in the middle of existing ones. There may also
be an issue of field ordering within each instruction.

But why do you want to do this? Have you lost your Lua sources?
--lhf