harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: timeframe for mid-level decissions
Date Thu, 19 May 2005 08:32:02 GMT
Hi Renaud,

thanks for your response on the technical side. See my coments inline.

Renaud BECHADE wrote:
> 
> >* Stay close to the operating system - GCJ,LLVM,... - See
> > http://www.research.ibm.com/vee04/Boehm.pdf
> 
> Especially as GCJ and LLVM (especially LLVM) are relatively fast, NOW.
> (I remember comparing some floating point test between gcc -O 10^8 and
> llvm-gcc + llvi. The llvm was damn fast on my machine - I think I had a 20%
> or 30% improvement, which is indeed quite good - so good as say the Intel
> compiler or so on Intel machines. That was a pity Objective-C was not
> available :-( )

Yeah its pretty agressive. Objective C is something which is very
intersting too - since they (apple) have one of the fastest dynamic
dispatch algorithms based on caching
[http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html].

> 
> >As a side node:
> >Also the LLVM guys are heavily thinking about implementing many
> >intrinsics based on APR and other core libraries. Sure there are many
> >things which have to be built yet (garbage collecter, memory model
> >(which is very low level right now) ...) but a llvm-java frontend is
> >arleady being worked on.
> 
> Since GCJ and GCC share the same code generator, and since GCC code
> generator has been ported to LLVM (with may-be heavy changes, though), why
> not just make sure a GCJ-LLVM-with-jit-plugin is developed, once GCJ gets
> some minimal support for java5 bytecode ("all-except-reflection")?

There are some things I'm working on as a side project for now. LLVM for
instance uses a different exception handling mechanism then GCC. But one
could work around this because LLVM has a very high level view of
exceptions (which is quite nice) - every invoke instruction has an
implicit catch target. So the way exceptions are actually implemented
can be user specific.

I personally see LLVM as a MIR but with the advantage of beeing well
specified. Jikes also has this sort of IR - but in LLVM you can see the
MIR as a kind of execution engine since it supports a type system and
has a well carried out binary representation. The binary representation
would help in many things for instance one could store optimizations in
the llvm bytecode format and reuse them later.

>From this side I'm also interesting in the c-- project which comes form
the ML/OCAML people. It is a very low level c representation, which
features continuations,exceptions, ... . [I haven't had time to look
through it carefully]

> So far as I know, LLVM enables or is scheduled to enable at-runtime LLVM
> bytecode generation (used for Ruby and Scheme interpreters I think[1]), so
> that we could have a cool JIT without the burden of actually generating
> low-level machine code (kind of a write once, run everywhere JIT).

 So you mean a JIT that generates LLVM bytecode - please tell me more on
that.
Actually there is a interpreter and a jit in the cvs tree. The JIt
(called JELLO) is special since it works with the target machine code as
if it was in SSA form. I don't know how good/bad this is practice, I've
just read the paper from 2002. You can come a long way with the
interpreter alone since it is very low levelish - many of the
optimizations is already done in in the bytecode - which is not possible
for HIRs like Java - and the registers are in SSA form so you have
superb data flow information available at no cost.

> This kind of plan could also have the theoretical advantage of being able to
> release early and on a very big bunch of architectures code that /actually/
> works, and is kind-of used by default by many, many, many people (*BSD
> users, embedded systems, linux hackers, and so on).

Yes thats true. Such a system would be very interesting, since you can
extend the VM with LLVM bytecodes and reuse many aspects. There is also
a new wave of building secure systems based on Proof Carrying Codes.
(PCC). Since LLVM has typed instruction set and needs explicit casts to
do type conversion (cast instruction) - you can say whether a piece of
code is type safe or not. I don't know how hard it would be to add proof
carrying codes into the LLVM. But if that would be enabled, a whole new
interesting possibilties would arise. (extending the VM by PCC based
LLVM instructions).
[http://www.cs.nott.ac.uk/~fxr/papers/2004_scp/franz_scp.pdf]

-- Jakob


Mime
View raw message