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

[<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

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