Re: Interpreters for VLIW

germana.ricci@inwind.it (Bonz)
20 Jan 2001 16:12:12 -0500

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.