lua-users home
lua-l archive

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

Greg <> writes:

> I've just been reading about the advances the SquirrelFish is making.
> It seems like they have learned a lot from Lua.  It is fascinating to
> see how this javascript implementation is becoming much faster.  It
> seems that they are employing many advanced optimizations.  It reminds
> me a lot of LuaJIT.
> One of the things they mentioned is "direct-threading".  Does Lua
> support direct threading? Just curious.

Hm, I know the terms "direct threading" and "indirect threading" from
Forth.  "Threaded code" is just a direct succession of memory addresses
to call.  Executing direct threaded code means fetching consecutive
memory words and jumping to the given address.  Indirect threaded code
means fetching consecutive memory words and jumping to the address
indicated by the memory contents at the given address.

Indirect threading makes for the most compact representation in memory:
typical data structures (including code) in Forth have their type and
behavior characterized by one memory word, and code consists just of a
succession of memory words pointing to them.  Direct threading is only
slightly less compact: type and behavior are characterized by one
function call (so typically take one byte or word more each), but the
bulk of the code is still a succession of addresses.

Either variant is usually suited well for execution in even the most
memory-starved environments (and we are talking here about a few
kilobytes, not at all what people tend to think about nowadays).

One point is that the "command set" of the interpreter written in that
way is open-ended.  A virtual machine with byte codes instead has a
closed set of commands, and for executing them, it still needs to go
through indirection and table lookup.

I don't think it makes much sense to work with one of the
direct/indirect threading models in that context.

David Kastrup, Kriemhildstr. 15, 44793 Bochum