Related articles |
---|
Re: C -> Java Bytecode napi@cel.mimos.my (1999-08-01) |
Re: C -> Java Bytecode olefevre@my-deja.com (1999-08-02) |
Re: C -> Java Bytecode s337240@student.uq.edu.au (1999-08-04) |
From: | s337240@student.uq.edu.au (Trent Waddington) |
Newsgroups: | comp.compilers |
Date: | 4 Aug 1999 01:14:20 -0400 |
Organization: | University of Queensland |
References: | <7o0gsb$cc0@ivan.iecc.com> 99-08-012 |
Keywords: | Java |
Mohd-Hanafiah Abdullah (napi@cel.mimos.my) wrote:
: I have been thinking about the same thing, i.e., targeting C source to
: the JVM.
I currently have JVM code generating and running.. VERY small examples
though.. I have gotten fibo:
int fibo(int i) {
if (i>1) return i;
else return fibo(i-1)+fibo(i-2);
}
int main() {
int i;
printf("Input Number: ");
scanf("%d",&i);
printf("fibo of %d is %d\n",i,fibo(i));
}
to work.. note that this transistion process is a part of the uqbt binary
translator project.. we actually do:
C -> sparc ELF binary -> lowlevel C + data files
-> Java Class file + data files
which could then be jar'd to a final executable (4 files for fibo).
I intend to allow the straight compilation of C -> Java Class file once I
have more working programs.. note that you can go from any binary file,
that uqbt has been resourced to, to Java bytecode. There's a problem with
global data (like the strings in the above example), when compiling string
from C, which has to be solved.. getting
LC0:
.ascii "Hello World!\n"
in your JASMIN file is not exactly useful.. I'm considering either moving
all this out into a GAS asm file and then objcopying it like we do for the
binary translated data or trying to put the data into fields within the
class file.. most real programs have large data sections which will bloat
your class file beyond the 64k limit.
Trent Waddington
Return to the
comp.compilers page.
Search the
comp.compilers archives again.