Related articles |
---|
Interpreters for VLIW bonzi@pc-amo3.elet.polimi.it (2001-01-11) |
Re: Interpreters for VLIW anton@mips.complang.tuwien.ac.at (2001-01-18) |
Re: Interpreters for VLIW jim.granville@designtools.co.nz (Jim Granville) (2001-01-18) |
Re: Interpreters for VLIW Xavier.Leroy@inria.fr (Xavier Leroy) (2001-01-18) |
Re: Interpreters for VLIW germana.ricci@inwind.it (2001-01-20) |
From: | germana.ricci@inwind.it (Bonz) |
Newsgroups: | comp.compilers |
Date: | 20 Jan 2001 16:12:12 -0500 |
Organization: | Mailgate.ORG Server - http://www.Mailgate.ORG |
References: | 01-01-076 |
Keywords: | architecture, optimize |
Posted-Date: | 20 Jan 2001 16:12:12 EST |
Anton, thanks for the pointer. I implemented a similar idea and got a
~20% improvement -- not as good as I wanted it to be, but a good
starter. It will be in version 1.95.1 of GNU Smalltalk, which I'll
put out by the end of the month; that version also has a JIT for the
x86 (of course my timings were without the JIT in both cases,
otherwise I'd be comparing apples to pears).
> For the IA-64 and PPCs you also have to consider the branch registers.
Yes. The compiler translates a "goto *t" to something like
mov b6 = r14
br.few b6
and does not schedule the two instructions. The register is loaded
way too late. By trial and error I found that "b4" is not used by the
compiler, so I could hard code "t" in that register using GCC's
__asm__ directive; having the destination of the branch in r14 hid
most of the performance benefits.
Some other tricks I used were to cache a few global pointers in
registers.
By the way, disabling global CSE results in comparable code and less
than 20% of the compile time when you are using computed gotos. (Have
you tried that out in Gforth?)
> In the following I'll assume you want to implement direct threaded
> code (right?).
Actually I use token threaded code to share most of the code between
the non-GCC and GCC versions of the interpreter. I load the branch
register at the start of the bytecode.
> I am currently working on a VM interpreter generator that does much of
> this automatically (it's based on Gforth's generator). It should be
> ready in a few weeks. Mail me if you are interested.
It's interesting indeed. Are you going to publish it on your web site?
Paolo Bonzini
Return to the
comp.compilers page.
Search the
comp.compilers archives again.