[478] in java-interest
Re: opcodes
daemon@ATHENA.MIT.EDU (Tom Lord)
Fri Jun 23 16:43:38 1995
Date: Fri, 23 Jun 1995 13:20:12 -0700
From: Tom Lord <lord@cygnus.com>
To: Arthur.Vanhoff@Eng.Sun.COM
Cc: java-interest@java.Eng.Sun.COM
In-Reply-To: <9506230636.AA11223@acorn.Eng.Sun.COM> (Arthur.Vanhoff@Eng.Sun.COM)
> If you are working on a VM or related code, why consider helping
> working on the GUILE VM? It is largely done and largely Java-compatible.
> With a little work, either or both jobs could be finished.
Please note that the Guile Virtual Machine is *NOT* Java compatible.
Right. It is "largely done and largely Java-compatible", meaning that
if someone wanted to put a little work into the problem, they could finish
a truly Java-compatible VM, starting from the Guile VM.
This is a little like the free software Java compiler I've read about
-- a lot of the work needed to implement it has apparently been done
and a bit more will finish the job.
I like to mention this possibility of making something truly Java
compatible starting from Guile because I think a Free Software
implementation of Java is a good idea. I think that a language like
Java with some static typing and close-to-native number formats
nicely complements a language like Scheme.
Finally, I think that the existing code base in Guile is close enough
to Java VM that doing the remaining work to embed a Java VM in Guile
is a viable way to obtain ports of Java. (I'm not sure how much work
it would take to reimplement free versions of the standard native
methods that underly the Sun compiler, AWT, and so forth).
We do not encourage the implementation of non compatible virtual
machines since there is no point in establishing a universal vm
if there aren't any guarantees of compatibility. It not in anyone's
interest if various "almost" compatible vms are floating around on
the net.
This is an exaggerated fear. Supposing that Guile settles on an
instruction set that is slightly different than the Java VM -- so
what? Is that a threat to Sun's proposed standard? I don't think
so; at least I hope it is not.
I'm sure it will be a simple matter for any programmer to write a
translator that allows official Sun Java Virtual Machine Standard
Byte-codes to run perfectly well on the Guile VM. Native binaries are
being translated between machines this way nowadays, and that is a
harder problem than translating VM binaries. Sounds to me like a fun,
small project.
It seems to me that the Java spec has thrown down the (nearly
unchallenged) gauntlet proclaiming a new, multi-platform standard for
binary object files (including a standard instruction encoding). In
my opinion, that was a good idea that is in no way undermined by the
details of the Guile VM. What instructions the Guile VM supports
natively has little bearing on what object file formats it will be
able to read and run. I don't think the Guile VM's internals should
necessarily be construed as a challenge to the Java exchange format.
One thing I quite like about the Java VM exchange format is that it is
already extensible. I am free to encode "extended instructions" as
ordinary static method invocations. A VM implementation is free to
translate these method invocations to something more efficient when it
comes time to actually run the code.
Supposing I encode some extended instruction as a call to function F.
The presense or absense of an (apparent) definition for F tells me
whether a particular Java VM platform supports the extension.
For example, the Guile VM might appear to have a native method "CDDR"
(for Scheme programs) but calls to this method might, in fact, be
translated upon first execution into the (hypothetical) Guile VM
instruction "i_cdddr". By checking for the "CDDR" method, I can tell
if a given Java platform will be able to run compiled Scheme code.
An intriguing possibility is that on some Java VM implementations, the
"CDDR" function might not be a built-in instruction but might really
be handled by an emulation library written in, say, Java. This
reminds me of co-processor instructions found on some processors only
instead of having the option to emulate hardware with software, we have
the opportunity to emulate native software with interpreted software.
This might be a viable way to port some code written in other
languages or for an extended VM to a strictly-Java platform.
Central to the goals of the Guile project is the goal of supporting
multiple languages. It is inevitable that the VM in Guile will gain
new built-in instructions for languages other than Java and possibly
even for a free implementation of Java. So it is not practical to
decide to constrain the Guile VM internals or native exchange format
to the Java VM spec -- but this says nothing against the validity of
the Java spec as a universal exchange format which to my eyes appears
unchallenged.
By the way, we fully support all serious efforts towards implementing
Java compatible virtual machines.
Good. If there are people who would like to work on a Free Software
implementation of Java VM, I encourage them to embed that
functionality in Guile, which already contains many of the necessary
pieces. As I said, this may be a good strategy for obtaining ports of
Java to some platforms.
We're open to any suggestions for improvements. However, we do not
encourage unilateral extensions like those in Guile.
It's true that Guile is more than just an implementation of Java and
so has functionality not found in Java. But because Guile is Free
Software I don't see how this additional functionality harms anyone.
-t
P.S.: More information about Guile is available at:
http://www.cygnus.com/library/ctr/guile.html
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
