Now that the GPL v3 looks as though it may be EPL-compatible, the time
has come to reconsider using the Eclipse java compiler ("ecj") as our
primary gcj front end. This has both political and technical
ramifications, I discuss them below.
Steering committee members, please read through if you wou
Technical approach.
Historically we've wanted to have a 'native' java-source-code-reading
compiler, that is, one which parses java sources and converts them
directly to trees. From what I can remember this was based on 3
things:
A couple of other factors:
* Compile time. It is at least poten
Hear, hear!
I think using ecj as a gcj front end sounds like a terrific idea!
Kind regards,
Thomas Hallgren
Tom Tromey wrote:
Now that the GPL v3 looks as though it may be EPL-compatible, the time
has come to reconsider using the Eclipse java compiler ("ecj") as our
primary gcj front end. Thi
Tom Tromey writes:
> Historically we've wanted to have a 'native' java-source-code-reading
> compiler, that is, one which parses java sources and converts them
> directly to trees. From what I can remember this was based on 3
> things:
>
> * In the past the compiler handled loops built wit
Andrew Haley wrote:
I think that from a maintenance point of view this would be a PITA.
Also, as Per mentioned we'd need to extend the .class file format in a
non-standard way to get full debugging information. In particular,
.class files don't contain the full pathnames to source files.
The "
On Friday 27 January 2006 09:10, Paolo Bonzini wrote:
> How big would the mini Java-runtime be? A bytecode-interpreter, with
> only support for two or three packages, using a simple Baker or
> mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less.
JamVM is pretty small, I doubt
> ecj is written in java. This will complicate the bootstrap process.
> However, the situation will not be quite as severe as the Ada
> situation, in that it ought to be possible to bootstrap gcj using any
> java runtime, including mini ones such as JamVM -- at least, assuming
> that the sugg
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
> [...] IMHO, writing your frontend in the same language it's intended
> to compile causes it to be marginalized. It no longer becomes part
> of the default bootstrap sequence and gets much less testing. [..]
Even if so, it may be worth spelling out
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
| - supplies "virtuous circle" motivation for improvement (speed,
| quality, ...), since it itself directly benefits
Fully agreed. Witness: GNU C :-)
-- Gaby
On Thu, Jan 26, 2006 at 05:08:20PM -0700, Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss the
> "Paolo" == Paolo Bonzini <[EMAIL PROTECTED]> writes:
Paolo> How big would the mini Java-runtime be? A bytecode-interpreter, with
Paolo> only support for two or three packages, using a simple Baker or
Paolo> mark'n'sweep GC, could be done in 10,000 lines of C code or maybe less.
The problem
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> A couple of other factors:
Thanks for bringing these up.
Per> * Compile time.
Yeah, this is a potential problem. If it is severe it could be fixed
by linking ecj into GCC. FWIW, at least for all the packaging we do
in Fedora, we have
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> In particular, the type system and the rules for exception
Andrew> regions are different. Also, a "slot" in the .class format
Andrew> doesn't necessarily correspond to a variable in the source
Andrew> language.
One way to look at
On Fri, Jan 27, 2006 at 11:59:06AM -0700, Tom Tromey wrote:
> Column numbers, as Per mentioned, are trickier. We know that ecj has
> this information (since Eclipse itself uses it), but there is no
> standard way to pass it via the class file format. But does gdb
> actually use column numbers?
N
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> But before fighting the political battles, we should first figure out if
Joe> this is what we really want to do if there weren't political obstacles.
Joe> Let's try coming to a technical consensus first.
I made a list of things which would
On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote:
> > ecj is written in java. This will complicate the bootstrap process.
> > However, the situation will not be quite as severe as the Ada
> > situation, in that it ought to be possible to bootstrap gcj using any
> > java runtime, includi
On Fri, Jan 27, 2006 at 11:09:11PM +0100, Laurent GUERBY wrote:
> On Fri, 2006-01-27 at 09:25 -0500, Kaveh R. Ghazi wrote:
> > > ecj is written in java. This will complicate the bootstrap process.
> > > However, the situation will not be quite as severe as the Ada
> > > situation, in that it ou
On Fri, 2006-01-27 at 17:17 -0500, Daniel Jacobowitz wrote:
> Two interesting things I'd like to point out here:
>
> - I don't know if it's been a problem lately, but GNAT definitely
> used to have issues with not just the language it was written
> in, but what specific version of the co
> "Laurent" == Laurent GUERBY <[EMAIL PROTECTED]> writes:
Laurent> If someone comes up with an old JVM that misrun java in GCC
Laurent> and there's no easy obvious workaround, will you cancel the
Laurent> java project or just tell the user to install a known to work
Laurent> JVM from the GCC i
> From: Laurent GUERBY
> Wether C++, Java or Ada, a new language requirement looks the same to
> me: having a good enough base compiler and runtime installed
> for the language, I do not see anything special to Java or
> Ada over C++ here. The base compiler I use for building GCC
> has only c,
As others have pointed out, there's potentially a small difference in
the case of Java, in that I believe the .class -> .o part of the
compiler would still be buildable without an existing JVM, and perhaps
even somewhat tested without one. And that's the part that's likely
Tom Tromey wrote:
> Now that the GPL v3 looks as though it may be EPL-compatible, the time
> has come to reconsider using the Eclipse java compiler ("ecj") as our
> primary gcj front end. This has both political and technical
> ramifications, I discuss them below.
First, I'd like to commend and t
> Also I believe not allowing new languages for new front-ends might
> limit the increase of language front-ends in the GNU Compiler
> Collection:
I think "not allowing" is too strong a characterization of my previous
message. I have neither the inclination or the power to do that on my
own.
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
[...]
| However with Tom's proposal, we need an existing java compiler for our
| target.
I don't believe the issues at hand here (Java specific case) are as
severe as they sound from your messages. If GCC creators had to
follow the reasoning develope
Another concern: I gather there are lots of dependencies
between Eclipse libraries. Does ecj depend on any other
Eclipse libraries? Even if there are no run-time dependencies,
it's awkward if a class statically references some random
Eclipse class that somehow pulls in large parts of Eclipse.
I
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Another concern: I gather there are lots of dependencies
Per> between Eclipse libraries. Does ecj depend on any other
Per> Eclipse libraries?
Good point. I forgot to mention this.
The Eclipse compiler is standalone by design.
The pro
> "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
>
> | However with Tom's proposal, we need an existing java compiler for
> | our target.
>
> I don't believe the issues at hand here (Java specific case) are as
> severe as they sound from your messages.
Okay fine, let's quantify it. I dow
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| > "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| >
| > | However with Tom's proposal, we need an existing java compiler for
| > | our target.
| >
| > I don't believe the issues at hand here (Java specific case) are as
| > severe as they sound
On Fri, 2006-01-27 at 16:41 -0800, Per Bothner wrote:
> I.e. I'm hoping one can *statically* link ecj without any
> dependencies on (say) the SWT toolkit, or the debugger?
Yes, you can. And when references have crept in by mistake, the Eclipse
guys were pretty quick about removing them.
BTW, the
Tom Tromey <[EMAIL PROTECTED]> writes:
> I think our technical approach should be to have ecj emit class files,
> which would then be compiled by jc1. In particular I think we could
> change ecj to emit a single .jar file.
I (and David Crawshaw) have actually done this.
http://tool.ibex.org/
Sorry to reply late to this thread. First I think concentrating on a
native bytcode compiler for java makes excellent sense it decouples
you from the front end implementation. And I agree that the eclipse
compiler is a good choice. I'd have to add that jikes is also
resonable.
I would like to say
> "Adam" == Adam Megacz <[EMAIL PROTECTED]> writes:
>> I think our technical approach should be to have ecj emit class files,
>> which would then be compiled by jc1. In particular I think we could
>> change ecj to emit a single .jar file.
Adam> I (and David Crawshaw) have actually done this
Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
do this.
In Java-5-mode I would expect ecj to use the unsynchronized
java.
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Tom Tromey wrote:
>> While investigating I realized that we would also lose a small
>> optimization related to String "+" operations. When translating from
>> .java we currently use a non-synchronizing variant of StringBuffer to
>> do th
Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
Tom Tromey dixit:
>In my preferred approach we would simply delete a portion of the
>existing gcj and turn jc1 into a purely bytecode-based compiler.
>ecj is written in java. This will complicate the bootstrap process.
Why not keep enough support in jc1 to bootstrap ecj?
Maybe split out so that
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> In particular, the type system and the rules for exception
> Andrew> regions are different. Also, a "slot" in the .class format
> Andrew> doesn't necessarily correspond to a variable in the source
>
> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
>> ecj is written in java. This will complicate the bootstrap process.
Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
We don't know how much of the language that would be.
Tom
Tom Tromey writes:
> > "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
>
> >> ecj is written in java. This will complicate the bootstrap process.
>
> Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
>
> We don't know how much of the language that would be.
An
Andrew Haley wrote:
Tom Tromey writes:
> > "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
>
> >> ecj is written in java. This will complicate the bootstrap process.
>
> Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
>
> We don't know how much of the language th
Andrew Haley dixit:
> > Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
> >
> > We don't know how much of the language that would be.
>
>And we can't tell _a priori_. As I understand it, the intention is to
>use upstream sources, and they will change.
Just keep the current state
> "Thorsten" == Thorsten Glaser <[EMAIL PROTECTED]> writes:
Thorsten> Why not keep enough support in jc1 to bootstrap ecj?
>> > We don't know how much of the language that would be.
>> And we can't tell _a priori_. As I understand it, the intention is to
>> use upstream sources, and they wi
42 matches
Mail list logo
