gcj and jikes
Geert Bevin
gbevin@uwyn.com
Fri Apr 25 19:28:00 GMT 2003
Hi Tom,
this sounds like a very good idea. I think however that the licensing
issues might be a major problem. It would be nice however to join the
efforts of java source code parsing instead of having to duplicate the
work each time for gcj. With the new features of jdk 1.5 that are
coming up, gcj will be lagging behind and a considerable amount of
effort will have to be done to catch up. If this can immediately be
integrated from the next jikes release I suppose support for these new
features will be much more easily obtained.
Just my 2c.
Btw if there's need for stupid integration work that can be done by
someone without much knowledge of the inner architecture, I'm willing
to help. In time I suppose I could get acquainted with more internal
details, but for now gcj is pretty much a black box to me. I don't know
if I can be useful, but you never know.
Best regards,
Geert
On vrijdag, apr 25, 2003, at 20:21 Europe/Brussels, Tom Tromey wrote:
> Last night I checked out the jikes source and looked through it a bit.
>
> I think it would be fairly easy to attach the jikes front end to gcj.
> This would be a vast improvement, since jikes is much better at
> parsing the Java language; for instance, jikes can compile Eclipse,
> whereas gcj cannot.
>
> Jikes represents most things at a pretty high level until it actually
> starts generating bytecode. So, we would just write our own generator
> which would generate GENERIC trees from jikes' internal representation
> (thus solving the tree-ssa problem as well). The main difficulty here
> would be that the gcc headers and such almost certainly aren't
> C++-friendly. So, we'd have to either fix them or write C helper
> functions.
>
> The gcj bytecode generator has some advantages over the one in jikes.
> gcj has a 2-pass generator that processes relocations in a second
> pass. So, where jikes will sometimes guess whether it needs a wide
> opcode, gcj never will. Also, gcj can only generate dead code in
> certain pathological situations. Porting the important parts of the
> gcj bytecode generator to jikes would be fairly straightforward, and
> in fact we could use the opportunity to get rid of the few remaining
> dead code generation problems (by reference counting basic blocks).
>
> To do an excellent job we'd also want to change the error output to
> conform to GNU standards. That shouldn't be very difficult, either.
>
>
> The biggest technical barrier I can see is representing debug info.
> Unfortunately this is an area I don't know very much about, so I'm not
> sure what we need out of a front end. Is information about variables
> and the starts of lines enough? Jikes already has that represented
> internally, since that is the debug info in a .class file.
>
>
> The non-technical barrier is licensing. jikes is under the IBM public
> license. We'd probably have to get some sort of special dispensation
> from RMS (and/or IBM) to do this.
>
> Tom
>
--
Geert Bevin Uwyn
"Use what you need" Lambermontlaan 148
http://www.uwyn.com 1030 Brussels
gbevin[remove] at uwyn dot com Tel & Fax +32 2 245 41 06
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
More information about the Java
mailing list