Re: Documentation for 5.2 VM instructions.

[Lorenzo Donati <lorenzodonatibz@...>]

Sorry for the late reply and thank you for the prompt one!

On 21/09/2011 10.38, KHMan wrote:
[...]
> Why don't you take it up? It seems to be a popular doc. I'll help out
> and you put your name first. :-) :-)
Alas, although it's a tempting offer :-) I must decline. (Very kind of 
you, anyway!) I've got very little free time and sadly I don't work as a 
developer any longer, so Lua is just an hobby for me and a way to keep 
my programming skills in good shape. I already do some basic beta 
testing for Steve Donovan's LDoc (with a very lax schedule from my side 
- given my time constraints) and that already saturated my "serious 
commitment bandwidth".

I'm not really an "assembler geek" (most serious assembly stuff is high 
over my head), but VM listings brings up some "ancient memories" to my 
mind: ~20 yrs ago I did some x86 asm programming at the university, but 
the real fun was programming a glorious Apple //e in machine language 
(sic - using handmade lookup tables and pencil and paper memory layouts 
- ahh! the pleasures of early youth :-) and debugging it using the 
miniassembler and the monitor program (call -151 anyone ?!? :-). Well 
the 6502 processor was so simple it was really fun, after all :-D

[...]
> Better to look at the opcodes, then lvm, and trace calls to other files
> from there.
Thanks for the pointer!

> > On a related note, out of curiosity I wonder if there is something
> > like an "assembler" targeting Lua VM. I know Lua VM specification
> > is a Lua implementation detail, but I'm curious to know if someone
> > has tried this way to enhance the performance of Lua in
> > time-critical code (assuming that hand-crafted Lua bytecode could
> > squeeze some cycles out of the VM).
>
> ChunkBake http://luaforge.net/projects/chunkbake/
> and also something by Zed Shaw in the past, IIRC.
>
> I don't think writing out bytecode assembly-style will give big
> performance wins. It's still interpreting... Mike Pall's Lua interpreter
> is already a lot faster, let alone the JIT.
Yes indeed! I never used it (I don't have the need for *that much* 
speed), but I'm always amazed by the reports about the performance of 
LuaJIT. The fact that it could beat pure C code in some cases is 
something unreal (at least for an uninitiated in compiler design like 
me)! I think I read somewhere (IIRC) it is deemed probably the most 
performing JIT compiler for a (dynamic?) language ever!

Most things that people have
> thought of will probably need modification of Lua source code (for
> example, a recent thread about reducing lookups).
>
> Maybe you want to try adding some super-instructions and see if there is
> a significant performance change -- what I would be real interested in
> right now is instruction traces and stats to show which bytecode pair
> (or chain) is most frequent...
>
> That said, I try to code a reasonable algorithm and that's it. Silicon
> is too cheap and it has wiped out most extreme optimization practices.
> All the same, as academic exercises, it's an interesting area.

Thanks for all the insight and for satisfying my curiosity!

Cheers!
-- Lorenzo