FYI: For a project in my company I am evaluating optimized native JIT
compilation right now.
I started with the perl compiler, which is a VM of about 300 complex
C-functions with pure stack handling, no registers. Simple but slow.
The perl op interpreter is a simple loop traversing the op-tree
while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
PERL_ASYNC_CHECK();
}
(see http://www.faqs.org/docs/perl5int/ops.html)
where the ops are already compiled, just the arg handling and traversal
is dynamic/interpreted. So this can be easily assembled JIT to native
code. But what would be the performance gains?
Perl5 has no type system and is very hard to optimize. There's a very
simple peephole optimizer which rewrites the tree inplace, superflous
ops are just NULLed and skipped.
Most of the time it is just pushing/popping args from the stack.
This should be optimized to handle registers somehow.
CLISP has a much better type-system, e.g. we would know most of the time
if we can do integer or double arithmetic. (handle overflows and
upgrades with exceptions or with an extra pre-check or after-check?)
CLISP also has the same advantage with perl that the bytecode
interpreter can call optimized native implementations of the opcodes,
very similar to perl (by calling the bytecode.d table functions).
But much better with numbers than perl of course.
So I'm also looking into JIT'ing and compiling clisp bytecode with the
GNU lightning library.
http://en.wikipedia.org/wiki/GNU_lightning
(i386, sparc and ppc only)
Does the CLISP VM uses only stack vars, no virtual registers? I've seen
none.
Has anyone looked into this before?
Am I missing an important point?
I'd need it for real-time within a system called INtime (on win32) where
our formula interpreter can only do 125 cycles per second (125Hz), and I
assume with native code compilation (dumping to dll's) or JIT at
init-time it will be able do 1-5 KHz at run-time.
Most of the time is sitting waiting for stupid global variables being
written to shared memory with 1KHz (so copy-on-write would be more
promising), but fast execution and lexicals would be nice to have anyway.
I'll keep you informed.
--
Reini Urban
|