lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Kevin,

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 http://www.zedshaw.com//writings/luas-lvm-instructions/ 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 located.

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:

Hi,

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 months.

- 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 replies.

If you've read this far, thanks for your time!

Cheers,

--
Kevin Coughlan        O+---+---+---+
                      || * |   |   |  Fier d'etre Acadien!
Radical Entertainment ||   |   |   |  On est venu pour rester!
Vancouver, C.-B.      |+---+---+---+


-----
Zed A. Shaw
http://www.zedshaw.com/