| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Considering the GNU c/c++ compiler for JOS could save a lot of work.
Reinventing the wheel for communication protocols or for the many file system drivers and hardware driver implementations hurts - JOS could benefit from the many GNU licensed linux sources. Of course, existing implementations will not work without proper additional work, but this task could surley be simplified (have a posix-layer in JOS..).
On the other hand, the gcc architecture with it's language front-ends would allow more languages than only c and c++ as source languages, objective-c, ada, pascal and more.
I had this idea when i came in touch with JOS, when i searched the deja news archive i came across pete gonzalez's article to gnu.misc.discuss from 1997/12/24, check out 7bdb97p620%7b%7b7ec20%7b%23*%23%20%26!20(sex20%7c%20jobs)%7d%7d%7d%7d&svcclass=dncurrent&threaded=1&ST=PS&CONTEXT=884702839.2076704814&HIT_CONTEXT=884702580.2073297116&HIT_NUM=22&REDO=1&recnum=3cPine.LNX.3.95.971224140943.23686B-100000@gimp.jefferson.ml.org3e%231/1">the whole thread.
Basically, he had the same idea, and there was some discussion going on on that point, read there. The big difference is, that pete thinks about replacing the JVM, which of course fits not into the JOS concept, but my idea was a gcc for the standard JVM.
I contacted pete via e-mail and told him about the JOS project.
Tasks/problems:
-- ChristianSchnell, 1998/01/13
The idea is nice, I also once thought about it, but it's not easy to implement. One of the main problems are really the pointers, in my opinion.
And one comment about the languages JOS will be able to support: right now all really important languages (except Visual Basic maybe) compile to Java class files if desired, except C/C++.
-- MarkusPeter
For more information on languages that compile to Java byte codes see http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html
-- IanDavis
I looked around a little bit and draw the following conclusions (so far, comments/corrections welcome):
Java frontend for gcc (.class -> .s)
Would allow to have gcc translate JVM instructions to native processor code (for all of gccs targets, which are many..), which then would be accessed through the java native interface (JNI).
Cygnus is implementing this, see
compiling java for embedded systems. This kind of compiler knows two realizations: as a just-in-time (JIT) or as
a ahead-of-time-compiler.
Cygnus aims at the second, which is a superset of a JIT-compiler and allows pre- and batch-compilation of existing .class files and even .java files (another javac-replacement, its really excellent what these guys are developing there..).
Interesting page from Cygnus for native C/C++-programs intended to run through JNI: Java/C++ integration.
Java backend for gcc (.s -> .class)
Not possible for all of gccs frontend languages. Especially not for C/C++ due to the assumed memory model in these languages.
The problem is: Suns processor instruction set does not allow to interpret numerical values as address values and vice versa. So standard C-constructs like int x = (int)&foo; simply cannot be expressed with Suns virtual processor instruction set. More detailed (quoted from Cygnuss compiling java for embedded systems):
... The executable content of a bytecode file contains a vector of bytecode instructions for each (non-native) method. The bytecodes are instructions for an abstract machine with some local variable registers and a stack used for expression evaluation. (The first few local variables are initialized with the actual parameters.) Each local variable or stack "slot" is a word big enough for either a 32-bit integer, a float, or an object reference (pointer). (Two slots are used for 64-bits doubles and longs.) The slots are not typed; i.e., at one point, a slot might contain an integer value, and, at another point, the same slot might contain an object reference. However, you cannot store an integer in a slot, and then retrieve the same bits re-interpreted as an object reference. Moreover, at any given program point, each slot has a unique type can be determined using static data flow. (The type may be "unassigned", in which case you are not allowed to read the slots value.) These restrictions are part of Java security model, and are enforced by the Java bytecode verifier. We do a similar analysis in jc1, which lets us know for every program point, the current stack pointer, and the type of every local variable and stack slot. ...
This means for C/C++, that not all constructs can be compiled to JVM instructions, a certain subset is - of course - allowed, but who needs limited C/C++?
-- ChristianSchnell, 1998/01/15
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|