[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: VM optimization (was Re: Re[2]: Still cryptic OOP syntax)
- From: David Olofson <david@...>
- Date: Mon, 31 Jan 2005 19:15:23 +0100
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
methods...
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---