Re: compiler back-end development?

"Ian Rogers" <rogers.email@gmail.com> wrote in message
> 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?


Java has a cost:
it is not C or C++...


the JVM has another cost:
it is not native code...


it is much like Linux vs Windows:
there is a big practical cost to using Linux: it is not Windows...


granted, Linux may soon come to compete with Windows, but one will be one
and the other, the other., and all other things being equal the cost may be
reasonable..




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


the conventional routes are more difficult, and not necessarily faster, but
there are plenty of other gains...


for example, in implementing a native-code C compiler, there is a great
benefit:
it is native code and C...




after all, even the JVM depends on native code and C, but native code and C
don't depend on the JVM.


likewise, the OS runs on native code, and not on the JVM, ...

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