Re: compiler back-end development?

Ian Rogers <rogers.email@gmail.com>
Fri, 17 Jul 2009 12:03:44 -0700 (PDT)

          From comp.compilers

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



Post a followup to this message

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