Re: Lua 5.1 Bytecode Question

[Olivier Delannoy <olivier.delannoy@...>]

On 1/9/06, Klaas-Jan Stol <vanderlay@home.nl> wrote:
> I forgot in the initial email, but there is also something changed in
> the header, as the reported register sizes do not match lua 5.0 sizes
> anymore.
>
> Anyway, I think it would be a good idea to provide for a
> backward-compatibility mode.
>
> regards,
>
> klaas-jan
>
> Tim Gogolin wrote:
>
> > I'm also interested in the response to this...
> > I write a lua "lint" like tool that works by analyzing byte codes and
> > looking for unexpected global references. Whenever I pull a new lua
> > version, that tool is always the first to break because the opcode
> > numbers no longer mean what they did before :-(
> >
> > -- Tim Gogolin
> >
> > On Jan 9, 2006, at 8:25 AM, Klaas-Jan Stol wrote:
> >
> >> Hi,
> >>
> >> I saw in the source of Lua 5.1 that there are 3 new instructions:
> >> 1. the modulo instructions
> >> 2. the "length" instruction
> >> 3. the vararg instruction
> >>
> >> I also saw that they were inserted in the middle of the list of
> >> isntructions of 5.0. I understand that you'd like the "MOD" op with
> >> the rest of the binary ops, but it makes things a bit harder when
> >> creating tools, such as a bytecode translator or something. Is  there
> >> any chance any new ops are added to the /end/ of the list of
> >> instructions?
> >>
> >> Kind regards,
> >>
> >> klaas-jan stol
> >
> >
> >
>
>
I haven't write a tool working at lowlevel like byte code. But I think
those tools are a special case and work at a level which should not be
accessed directly. The bytecode of lua is it's own property and should
remain easy to update and without constraints  for the lua
developer's. Public API have to change as little as possible but the
internal of the tools should not be publicly available for a few
reason begining with the pleasure of the authors. If one cannot make
change to the internal of its program because other might relies on
such private level introduce limit to the  creativity and development
of software like lua. A better solution whould consists in providing a
supporting header for ones working directly at bytecode level or even
a small set of function that whould be usefull for tools working on
the bytecode. I think of a bycode manipulation library that would be
able to deal with the various version of the bytecode.