harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From acoli...@apache.org
Subject Re: Compilation of other languages
Date Sat, 14 May 2005 19:19:44 GMT
I'd actually like to at least entertain the architectural idea implied 
by other "language" support.

So it may suprise a few of you to know that I've been researching VM 
technology underpinnings for some time prior to learning about Harmony 
for the purpose of another project (which I do not wish to discuss 
here).  I consider VM tech to be at the forefront of computing research. 
  This is still the hot-shit that we should all be thinking about 
instead of arguing about who has the best web framework.  Of course, I 
only like hard problems.

Let's determine what we should mean by that:

1. Compiling other languages into Java bytecodes - Compiler concern. 
This isn't too hard supposing that there are Java bytecodes that 
represent all of the proper operations that you wish to support.  First 
off it is impractical to compile a lower level language than Java 
(something with points) into Java bytecode (yes its theoretically 
possible so long as there is no direct device access or things that Java 
simple CANNOT do) without paying a high performance price.  Write a 
compiler with pluggable front ends, a proper MIL and the LIL would be 
the java bytecode.  Ironically you'll find you know a lot more about 
JITs and VMs when your done.  The cool thing is that you can actually 
write this in Java without breaking any new ground.  And Java is 
probably a fine language to write it in.  For people interested in this 
I recommend the "Tiger Book" which comes in a Java edition. 
http://www.cs.princeton.edu/~appel/modern/ - Its actually quite sensible 
to write such a compiler in Java.  I recommend borrowing the technique 
that THE java compiler uses with regards to operating on collections of 
files rather than single files (like C compilers).  Hell I'd recommend 
that for the C compiler too if it can be done practically (because my 
god it takes a long time to compile a large C program and not so long 
these days to compile a large Java program)

2. Interpreting other bytecodes with the HarmonyVM - this is quite 
possible and might even be done in a performant way.  By tweaking your 
primordial classloader or having multiple primordial classloaders. 
HarmonyVM may already require its own instruction set for reinterpreting 
bytecodes into type-specfic bytecodes and other thing needed for 
optimization.  Its not that much of a stretch to have a slightly larger 
instruction set which encumpasses both say .NET IL and JAVA IL and finds 
common ground between them.  The difficulty is of course JNI vs .NET 
unsafe code and the likes.  You're also not necessarily breaking a lot 
of new ground (http://www.ikvm.net/).  Though doing it deeper inside the 
VM could give you more opportunities for optimization.

If modularity is an objective than pluggable interpreter/JIT and 
speaking a compromise language between .NET IL (which is over all better 
IMHO than Java bytecode) and Java and whatever Python and friends use 
(assuming that they fall in the #2 category of having bytecodes, but I 
haven't joined the Python cult because I find it difficult to read, and 
I know enough languages that are difficult to read but perform better ;-) )


Humberto S. N. dos Anjos wrote:
> As far as I know, you don't have to convert your source code written in 
> Python, for example, to Java before compiling. It's an easy way out, since 
> you only map Python structures to Java classes and let javac do the heavy 
> lifting, but not strictly necessary. Since the JVM only understands 
> bytecodes, if I give it bytecodes it'll be happy. The compiler is the one 
> responsible for converting your source code in bytecodes for the JVM, so 
> you're essentially suggesting for Harmony to provide compilers for other 
> languages instead of only Java, so that my code written in Java could be 
> used in my VB code, for example. Interesting possibility, but since the 
> primary objective seems to be a 100% compatible JVM, that's something of a 
> side goal. Of course, if somebody wants to create the extra compilers, their 
> code is pretty much independent from the Harmony VM code, so go ahead.
> Now, about supporting the .NET languages... I've read some serious critiques 
> about Managed C++ and VB.NET <http://VB.NET> on the Internet, and C# has 
> several structures inexistent in Java (structs, delegates/events) that 
> require some careful thought to avoid inefficient code generation.
> Comega<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/html/xml01142005.asp>seems
> even worse, allowing SQL and XML syntax in the middle of your code
> (!!!), as well as adding extra structures (anonymous structs, streams, 
> choice types, nullable types, among others) to properly map these new 
> additions. That's supposing you won't support the .NET libraries, which 
> would render the whole effort nearly useless. Honestly, I don't think that, 
> for now at least, this should be a concern. 
> []'s
> On 5/14/05, tumnus@mac.com <tumnus@mac.com> wrote:
>>I am guessing that one reason for Harmony's modular approach will be
>>to support the compilation of other languages straight to byte-codes,
>>without having to convert into Java source first. I think there is a
>>definite need to handle the .Net set of languages (assuming there
>>were not patent problems), but what others might we need?
>>Also, would we need something akin to Bison writing?
> _______________________
> Humberto S. N. dos Anjos, SCJP 1.4, SCJP 5.0

Andrew C. Oliver
SuperLink Software, Inc.

Java to Excel using POI
Commercial support including features added/implemented, bugs fixed.

View raw message