Re: JIT Help...

anton@mips.complang.tuwien.ac.at (Anton Ertl)
4 Mar 2001 01:51:30 -0500

          From comp.compilers

Related articles
JIT Help... jakmal@bpssystems.com (J. Akmal) (2001-02-23)
Re: JIT Help... danwang+news@cs.princeton.edu (Daniel C. Wang) (2001-02-25)
Re: JIT Help... torbenm@diku.dk (2001-02-25)
Re: JIT Help... andi@complang.tuwien.ac.at (2001-03-01)
Re: JIT Help... pmb@dina.kvl.dk (Peter Bertelsen) (2001-03-01)
Re: JIT Help... jakmal@bpssystems.com (J. Akmal) (2001-03-01)
Re: JIT Help... anton@mips.complang.tuwien.ac.at (2001-03-04)
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (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

  torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>"J. Akmal" <jakmal@bpssystems.com> 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
>>either.


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
>translator.


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
http://www.complang.tuwien.ac.at/forth/performance.html)


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
benchmarks.


          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
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html


Post a followup to this message

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