Related articles |
---|
[5 earlier articles] |
Re: compiler back-end development? ian@airs.com (Ian Lance Taylor) (2009-07-13) |
Re: compiler back-end development? cr88192@hotmail.com (BGB) (2009-07-13) |
Re: compiler back-end development? cr88192@hotmail.com (BGB / cr88192) (2009-07-14) |
Re: compiler back-end development? rogers.email@gmail.com (Ian Rogers) (2009-07-14) |
Re: compiler back-end development? cr88192@hotmail.com (BGB / cr88192) (2009-07-14) |
Re: compiler back-end development? toby@telegraphics.com.au (toby) (2009-07-15) |
Re: compiler back-end development? rogers.email@gmail.com (Ian Rogers) (2009-07-17) |
Re: compiler back-end development? cr88192@hotmail.com (BGB / cr88192) (2009-07-17) |
From: | Ian Rogers <rogers.email@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 17 Jul 2009 12:03:44 -0700 (PDT) |
Organization: | Compilers Central |
References: | 09-07-013 09-07-01509-07-020 <m3y6qs1v1l.fsf@pepe.airs.com> 09-07-031 09-07-036 09-07-041 |
Keywords: | practice, Java |
Posted-Date: | 17 Jul 2009 16:56:54 EDT |
On Jul 14, 8:09 pm, "BGB / cr88192" <cr88...@hotmail.com> wrote:
> "Ian Rogers" <rogers.em...@gmail.com> wrote in message
> > FWIW, MRP [1] is in the process of supporting x86-64 as well as
> > currently support PPC32/64 and IA32. MRP is written in Java, which
> > gives a somewhat cleaner code base and the other usual productivity
> > gains from a managed language. It also has non-optimizing support for
> > Win32 but not yet Win64. The compiler back-end is based on iburg and a
> > linear scan register allocator. It currently not only hosts a Java
> > platform but a binary translator (supporting ARM, x86 and PPC) with
> > some early work on a Parrot VM too.
>
> Java?...
> is it worth the cost?...
>
> then again, since apparently they are their own JVM, it is maybe not as
> bad...
From my pov, the main thing when implementing a language, binary
translator... is not to get your hands burnt when doing the
implementation and increase your productivity on the interesting bits.
Java is good in those respects, strongly typed, good IDE support, no
memory bugs... It's not perfect. Building languages into an existing
VM means you also leverage the GC algorithms. I'm not sure where there
is a cost? In terms of the produced code it can be as tight as any
code generated by a C/C++ platform. Memory management is sufficiently
optimized to not be a performance issue (e.g. escape analysis to
allocate objects on the stack..). There is no initial JIT overhead as
the VM has precompiled itself and anything else it would find useful.
It strikes me there are more costs in conventional implementation
routes. I've written more here on this subject here [1].
Regards,
Ian
[1] http://oreilly.com/catalog/9780596517984/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.