Re: JIT Help... (Anton Ertl)
4 Mar 2001 01:51:30 -0500

          From comp.compilers

Related articles
JIT Help... (J. Akmal) (2001-02-23)
Re: JIT Help... (Daniel C. Wang) (2001-02-25)
Re: JIT Help... (2001-02-25)
Re: JIT Help... (2001-03-01)
Re: JIT Help... (Peter Bertelsen) (2001-03-01)
Re: JIT Help... (J. Akmal) (2001-03-01)
Re: JIT Help... (2001-03-04)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 4 Mar 2001 01:51:30 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-02-121 01-02-130
Keywords: tools, Java
Posted-Date: 04 Mar 2001 01:51:30 EST (Torben AEgidius Mogensen) writes:
>"J. Akmal" <> writes:
>>I just got done writing a compiler and VM (stack based) for a custom
>>language, and now I need to attack the JIT. I only need to support the
>>Pentium and Mac PowerPC. I don't need to squeeze every once of speed out

Then I would suggest sticking with an interpreter.

>The first thing you do is to determine the memory model you want to
>use. This includes which registers you want to use for stack pointers,
>if the stack grows up and down, if the SP points to the last used
>stack element or the first unused, where the stack limit is stored and
>what to do when tehre is overflow etc. A good start for this is to
>write an interpreter for your VM in assembly language.

I suggest using GNU C instead. It's portable, as fast as assembly
language for this purpose (if you do it right), and you can let the
compiler generate assembly language if you want to.

>Once you have done this, it will probably be a simple manner to
>describe each of your VM instructions as a sequence of simple
>operations on this state, including which registers are used etc.
>These simple operations can typically easily be expressed as short
>machine-code segments. You now basically have a VM to machine-code

If you want to generate fast code (and why else would you write a
JIT?), then forget about this macro-expansion approach, and map stack
items to registers, as you outline later.

>The resulting JIT will be fast at generating code, but the code
>performance won't be stellar - probably 4-10x the speed of interpreted
>VM code.

4-10x is the difference between an efficient interpreter and optimized
C code for small benchmarks. A macro-expansion approach, even with
some peephole optimization, gets more like a factor of 2-3 (see

Also, for larger benchmarks the speedup is often less; e.g., we have
recently written a threaded-code version of the Cacao JVM JIT. The
native-code variant translates stack and locals accesses into register
accesses. Sieve is a small benchmark, db and javac are larger

          native threaded factor
sieve 1.45 18.88 13.02
db 65.54 145.27 2.22
javac 10.15 22.14 2.18

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

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