Re: using gcj for a different language - is it possible?

["Florin" <fmateoc at mfire dot com>]

Tom,

Thank you for your reply.
I embedded some comments/new questions below.

----- Original Message ----- 
From: "Tom Tromey" <tromey@redhat.com>
To: "Florin" <fmateoc@mfire.com>
Cc: <java@gcc.gnu.org>
Sent: Monday, January 05, 2004 2:32 PM
Subject: Re: using gcj for a different language - is it possible?


<snip>

> I think there are a few plausible choices open to you.
>
> One is to put the Smalltalk class library into a package in the Java
> namespace.  E.g., "com.mfire.fmateoc.smalltalk".  Then you can
> transform Smalltalk code directly to Java code (or bytecode) and avoid
> any gcj hacks.

I am afraid of what the performance would be like if Smalltalk literals
would become non-base classes. After all, the major itch that I am trying to
scratch here is performance.

> Another choice is to make it possible for the gcj and smalltalk
> runtimes to inhabit a single address space.  I.e., ensure that the
> various low-level parts of the two runtimes can be shared: a common
> view of threads, files, garbage collection, etc; but otherwise having
> separate type and object universes (perhaps with some sort of bridge,
> I dunno).  I'm idly interested in seeing things evolve this way.

Could you please elaborate a little more?

One other option might be to start from the Objective-C front-end,
Objective-C being very close to Smalltalk(80), but I know that it lacks
blocks (in particular those surviving longer than the methods that created
them), which can be simulated in Java with anonymous classes. Are the two
runtimes (gcj and Objective-C) similar/related?  Is there any bridge between
the two? From an outsider's perspective, I would think they should be pretty
close.

And one last question (for now :)
Does gcj use the Java static type information for optimizations (inlining)?

Thank you,

Florin