Re: Lua v4 vs. Lua v5

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

Zed Shaw wrote:

>I have started writing a document to record what I've figured out so
>far about the VM since I'm working with it at the "assembly" level.

Nice. Lua could use an assembler. I have the beginning of one somewhere
and I think someone else had written one. But it was for Lua 4.0.

The problem with working with the Lua VM instructions directly is that
the Lua VM is only a tool to implement Lua, not a product on its own.
It can change radically from one release to another (as it did in Lua 5.0),
even if the language changes little or nothing.

But I don't want to discourage you. As far as we can tell, the current VM
is likely to remain stable, but no promises...

>3.  The way "objects" are handled has changed so that metatables are  
>used rather than tags.  I found this annoying since I couldn't find any  
>documentation on how to convert from the old to the new.

It's supposed to be pretty simple: everything is now ordinary Lua stuff.
Perhaps we need an emulation of the tag scheme on top of metatables. If
nothing else, to show how things work now.

>4.  Many of the functions in the standard library have changed so that  
>they are in namespaces (like io.open and such).  This is good for new  
>stuff, but it royally screws things up for existing code.

Try etc/compat.lua.

>6.  There's apparently a foreign function call interface built in, but  
>I can't find docs on this.

What do you mean?

>One thing I have noticed is that the Lua compiler (in both 4 and 5)  
>produces inefficient code.  It has redundant opcodes, unnecessary  
>variable copying and other things.  I'm curious if anyone has attempted  
>to add optimization to the process or if they think it would be useless?

The code generator does some optimizations, specially in conditionals,
but it does not remove dead code, for instance. Here is an example:

% cat a ; /tmp/lua-5.0/bin/luac -l a
if true then
 print "yes"
else
 print "no"
end

while true do
 print"loop"
end

main <a:0> (13 instructions, 52 bytes at 0x805b598)
0 params, 2 stacks, 0 upvalues, 0 locals, 4 constants, 0 functions
        1       [2]     GETGLOBAL       0 0     ; print
        2       [2]     LOADK           1 1     ; "yes"
        3       [2]     CALL            0 2 1
        4       [2]     JMP             0 7     ; to 12
        5       [4]     GETGLOBAL       0 0     ; print
        6       [4]     LOADK           1 2     ; "no"
        7       [4]     CALL            0 2 1
        8       [7]     JMP             0 3     ; to 12
        9       [8]     GETGLOBAL       0 0     ; print
        10      [8]     LOADK           1 3     ; "loop"
        11      [8]     CALL            0 2 1
        12      [7]     JMP             0 -4    ; to 9
        13      [9]     RETURN          0 1 0
--lhf