ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | architecture List | September 2003 Index

<--  Date Index  --> <--  Thread Index  -->

RE: Re-4: [ObjectWeb architecture] just an idea for (Java) native compilation


>===== Original Message From <markus.karg@xxxxxxxxx> =====
>Dominique,
>
>Actually not GCJ is reinventing the whell, but you do:
>
>- AFAIK GCJ is basing on GCC, a compiler framework that comes with a common 
optimizing backend, exchangeable frontends and code creation engines. This 
means, GCJ is GCC supplied with a platform specific code creation engine 
(x86) 
plus a Java
>frontend (Java parser). Also the backend is platform dependend, which means, 
the machine code creation engine can be changed to produce Java Binaries, x86 
Machine Code etc. I cannot see any reinvention here.
>
>- Actually your compiler does not exist but only is an idea on the paper. 
Since I did not hear of any breaking news from you, I am assuming that it is 
just another compiler, that compiler OCaml language into x86. So what is the 
difference here? Why
>is your compiler NO reinvention of existing compiler technology? Why not 
>just 
adding an OCaml frontend to GCC instead to prevent reinvention of backend 
(optimizer, code creation)?
>
>What actually (in one sentence) is your invention, if you think GCJ is a 
reinvention but OCaml-Compiler is not?
>
>Have Fun
>Markus

Markus,

Your remarks (this email and the others) are valid.

I don't exclude to be wrong, even at 100 % :-)

May be I am still thinking too much about 1996-1997 where Java was emerging, 
with slow VM, and people thinking about Java compilation, while Caml 
compilation was already (!) existing (if my memories of my 199x's Caml 
programmation are correct). And then, at this time, I was already hoping 
about 
"some" knowledge "transfer". So my connexion Caml-ObjectWeb consortiums (with 
OCaml intermediary step *if* needed). But this may be too late to be worthty.

I remember also old times (199x) where great names (Kernighan, Pike...) at 
Bell Labs were designing a new-C-language called Limbo (for embedded purposes 
I think), some kind of Java but non-OO and running also on VM but 
registry-based and specific memory model (see 
<http://www.vitanuova.com/inferno/concepts.html> and more precisely, The Dis 
Virtual Machine Specification at 
<http://www.vitanuova.com/inferno/papers/dis.html>). They have written 
somewhere that the *first* JIT Limbo VM, they have developped, contained in 
1600 lines of C and was achiveing 1/2 of the performance of C equivalent 
programs (few lines of code for Limbo VM due to easy mapping between Limbo VM 
and read hardware) ! Not too bad compared to the first JIT Java VM (but, of 
course, Limbo was non-OO but even if module-based) ! Reading that, I was 
wondering again about some Java technological choices (for example, why a 
stack VM as most hardwares are registry based ? this is against 80-20 rule) 
and knowledge "transfers".

I think there is plenty room for innovation but my previous emails have a 
strong chance :-) to be useless (too late), except might be in embedded 
systems. Forget it !

Have fun also,
Dominique



>-------- Original Message --------
>Subject: RE: Re-2: [ObjectWeb architecture] just an idea for (Java) native 
compilation (25-Sep-2003 16:44)
>From:    dominique.devito@xxxxxxxxxxxxxxx
>To:      markus.karg@xxxxxxxxx
>
>> >===== Original Message From <markus.karg@xxxxxxxxx> =====
>> >Oh, now I understand. So is the OCaml compiled native code faster than the
>>
>> code from other compilers, e. g. from GCJ?
>>
>> Sure, GCJ is existing and my hypothetic compiler is still in paper form.
>>
>> But, when I read news in the GCJ home page <http://gcc.gnu.org/java/>, I
>> wonder if GCJ developers are not reinventing the wheel, step by step, when
>> focusing to a high-performance native compiler. And then, I wonder if I
>> would
>> be simpler for join strengths.
>>
>> The same when I read that Python guys want to develop a native compiler, I
>> wonder why they don't generate some OCaml code as Python and OCaml are so
>> close.
>>
>> Of course, same as above : if GCJ provides what most people expects today (
>> I
>> have not enough knowledge about it to validate this or not), nobody has to
>> care about my compiler in paper form !
>>
>> Dominique
>>
>>
>>
>> >Do you have benchmarks (I'm really interested in getting Java running
>> faster)? For the second point: Sure constructing an
>> >ObjectWeb own native java compiler is interesting, but do we have manpower
>>
>> for such a project?
>> >
>> >-------- Original Message --------
>> >Subject: RE: [ObjectWeb architecture] just an idea for (Java) native
>> compilation (25-Sep-2003 11:08)
>> >From:    dominique.devito@xxxxxxxxxxxxxxx
>> >To:      markus.karg@xxxxxxxxx
>> >
>> >> >===== Original Message From <markus.karg@xxxxxxxxx> =====
>> >> >Maybe I have not quite understood what the benefit of a cross
>> compilation
>> >> from Java to OCaml should be. Java is fast already and if I want to make
>> it
>> >>
>> >> faster, I would prefer native compilation (machine code) instead of
>> OCaml.
>> >> Cross compilation
>> >>
>> >> I also focus here native compilation for Java but between the Java code
>> and
>> >>
>> >> the binary code, I have just talked about an intermediary step : the
>> OCaml
>> >> code.
>> >>
>> >>
>> >> >between Java and OCaml would weaken the idea of one common Java
>> platform,
>> >> since it would degrade Java to one of many possible source languages for
>> >> OCaml. But instead, the idea behind Java is that it is the only target
>> >> platform itself. So I will not
>> >> >support this idea.
>> >> >Also OCaml is seldomly used, while Java is widely spread. So I only see
>> a
>> >> benefit for OCaml, not for JOnAS.
>> >>
>> >> No degradation here for my point of view : the OCaml language is used
>> here
>> >> as
>> >> an intermediary step for Java native compilation. Just as the first C++
>> >> compilers. The C language was used for the intermediary step : C++ -> C 
-
>> >
>> >> native code and this compilation way has not weakened the C++ language
>> and
>> >> it
>> >> was not for the benefits of C.
>> >>
>> >> Instead of generating OCaml code from the Java code, another way might
>> be
>> >> to
>> >> reuse&share some parts of the outstanding OCaml compiler in order to
>> build
>> >> a
>> >> Java compiler.
>> >>
>> >> Just my 2 cents.
>> >>
>> >> Best regards,
>> >> Dominique De Vito
>> >>
>> >>
>> >> >Have Fun
>> >> >Markus
>> >> >
>> >> >-------- Original Message --------
>> >> >Subject: [ObjectWeb architecture] just an idea for (Java) native
>> >> compilation
>> >> (24-Sep-2003 21:56)
>> >> >From:    dominique.devito@xxxxxxxxxxxxxxx
>> >> >To:      markus.karg@xxxxxxxxx
>> >> >
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> This is just an idea for (Java) native compilation.
>> >> >>
>> >> >> INRIA has an outstanding knowledge about native compiler technology.
>> To
>> >> be
>> >> >> more precise, INRIA has developped a native compiler for the "
>> Objective
>> >> >> Caml" language. Caml is a strongly-typed functional programming
>> language
>> >> >> from the ML family. OCaml (Objective Caml) and Caml Light are two
>> open
>> >> >> source implementations of Caml developed at INRIA Rocquencourt,
>> projet
>> >> >> Cristal. See <http://caml.inria.fr/> and 
<http://caml.inria.fr/ocaml/>
>> .
>> >> >>
>> >> >> INRIA has started at January 2001 the Caml consortium (like the
>> >> ObjectWeb
>> >> >> consortium) : the Caml consortium federates the design and
>> development
>> >> of
>> >> >> the Caml language and its programming environment. The Objective Caml
>> (
>> >> >> OCaml) compiler is released by the Caml Consortium and performs very
>> >> well :
>> >> >> Objective Caml ranks 2nd on speed (between C and C++) on Doug Bagley'
>> s
>> >> >> computer language shootout ! See
>> <http://www.bagley.org/~doug/shootout/>.
>> >>
>> >> >>
>> >> >> So, why not joining Caml & ObjectWeb consortiums strengths for
>> >> developping
>> >> >> a Java compiler ? One way could/would be to develop a bridge Java->
>> OCaml
>> >> as
>> >> >> OCaml's object-oriented features are similar to Java's object-
>> oriented
>> >> >> features (Ocaml also includes functional features, module 
features...)
>> .
>> >> >>
>> >> >> What do you think about this idea ? Silly idea :-) ? Good idea ?
>> >> >>
>> >> >> Best regards,
>> >> >> Dominique
>> >> >>
>> >> >>
>> >> >>
>> >> >> To: architecture@xxxxxxxxxxxxx
>> >>
>> >>
>> >>
>> >>
>> >> To: markus.karg@xxxxxxxxx
>> >>     architecture@xxxxxxxxxxxxx
>>
>>
>>
>>
>> To: markus.karg@xxxxxxxxx
>>     architecture@xxxxxxxxxxxxx




<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.