[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua v4 vs. Lua v5
- From: Zed Shaw <zedshaw@...>
- Date: Wed, 18 Jun 2003 00:47:00 -0700
Hi, just a note about what I've seen so far since I've been writing
trying to write a compiler that runs R on the Lua VM. 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. The doc is at
luas_lvm_instructions.html but it's very rough. The interesting part
would be at the end where the detailed instructions for each opcode is
I've noticed these things so far based on this (others can correct me
if I'm wrong):
1. The tailcall feature is implemented well, so if your code uses
classic functional recursion to process data, then you should see a
massive speed improvement and reduction in memory. Alright, maybe
massive speed, but definately a reduction in memory. This is because
(according to the docs) the a tailcall is handled by running the next
function call within the same stack as the current one.
2. Function calls that are internal to Lua apparently use a "faster,
register based virtual machine". I believe this only applies to
internal Lua function calls and other operations, but the C API is
still stack based.
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.
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. I'm still
trying to convert many of my scripts over.
5. While this may not matter to you, I've found that the docs for the
"test" opcode are totally wrong. I've got an extensive diatribe about
this in the doc I mentioned above.
6. There's apparently a foreign function call interface built in, but
I can't find docs on this. I'm actually really interested in this
aspect so I may research it further.
7. There's a lot of features to improve the stability of the VM, such
as the integrity checking of pre-compiled binaries, better integration
with the C api and garbage collector, ability to hook objects into the
GC via metamethods, and lua_atpanic for clean up.
Now, as for the debugger, I believe that there was one before, but that
I couldn't get it to work. It might be interesting to see what could
be done with debugging the code. Maybe chat with me off line about
possibly writing a cross platform one.
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?
Zed A. Shaw
P.S. Radical Huh? That's out in Vancouver right? I probably work two
blocks from you...
On Tuesday, June 17, 2003, at 01:46 PM, Kevin Coughlan wrote:
My team has just released a console game that uses Lua v4 (with yield
patch) for in-game scripting. We are quite happy with Lua!
We are now in pre-production for our next game, and we want to expand
on our use of Lua. I've scanned the archives of the mailing list and
also the documentation on the Lua site, but I'm having a hard time
getting good information on the following:
- Lua v4 vs. Lua v5: if we're not interested in coroutines, is it
worth upgrading to Lua v5? We found v4 to be quite stable, and we're
a bit leery of moving to v5, given that it's only been out for 2
- Integrating a debugger: in our previous game, our script writers
had to use the venerable "shotgun printf's" debugging technique. :)
We would now like to investigate the integration of a run-time Lua
debugger into our game. Are there any off-the-shelf solutions? Do we
have to roll our own? I don't have much experience with that, and I'm
wondering how onerous this task would be. On April 24th, 2003, Chris
Jacob posted a similar question, but I don't think he received any
If you've read this far, thanks for your time!
Kevin Coughlan O+---+---+---+
|| * | | | Fier d'etre Acadien!
Radical Entertainment || | | | On est venu pour rester!
Vancouver, C.-B. |+---+---+---+
Zed A. Shaw