Re: Documentation for 5.2 VM instructions.

[KHMan <keinhong@...>]

On 9/21/2011 12:55 PM, Lorenzo Donati wrote:
> Is there already a "No-Frills Introduction to Lua 5.1 VM
> Instructions" for 5.2 VM [1] or any equivalent higher level
> documentation (higher than browsing the source, I mean)?

Nope, I plan to focus on LuaSrcDiet (via Yueliang). Probably after 
the official 5.2 release...

I think a 5.2 update to No-Frills should switch back to luac.

Why don't you take it up? It seems to be a popular doc. I'll help 
out and you put your name first. :-) :-)

> Or at least a document describing the differences between 5.1 and
> 5.2 that can be found when browsing a VM listing?

None that I know of.

> Playing with luac listings in 5.2 I noticed a GETTABUP mnemonic.
> Any more differences?

Better to look at the opcodes, then lvm, and trace calls to other 
files from there.

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

> Any pointer appreciated!
> Thanks.
[snip]

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia