lua-users home
lua-l archive

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

On Monday 31 January 2005 17.15, Mark Hamburg wrote:
> Not applicable to Lua without whacking pretty much everything, but
> Forth is very interesting in this regard by virtue of having
> separate operand stacks and return address stacks. Since every Forth
> word (subroutine) is either a primitive or a sequence of other Forth
> words, it becomes straightforward to recognize common subsequences
> of Forth words and first define them as words in their own right
> (code compression) and re-implement them as native code
> (optimization) if appropriate. 

That means operations and operands are inherently lists, rather than 
trees? That's obviously very handy, but isn't that pretty close to 
what you get if you optimize somewhere close to, or on the generated 
code for any normal CPU or VM? Peephole optimization, that is. Works 
whether you want shorter/faster sequences or complex instructions.

> Unfortunately, modern processors aren't quite as friendly
> toward Forth as they might be.
> More in keeping with the conventional byte-code model is to use
> bottom-up tree-rewriting to use complex instructions. lcc does this.

Do you have any links related to this?

When parsing expressions, the EEL compiler constructs trees of 
"manipulators" rather than generating VM code directly. This is 
mostly for other reasons, but I quickly realized that these 
structures would lend themselves nicely to various optimization 

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> -'
   --- --- ---