＞Hmmm, interesting... I wonder if we could hook directly into the
＞compiler intermediate representation instead of having to write a big
＞string using C syntax and fire a parser on it.
＞Does anybody know if GCC allows such a thing?
＞Keep in mind I know squad about GCC and friends.
Well, one solution is to send ... java bytecode to gcj...
Or again write LLVM opcodes/bytecodes.
This would be kind of a Squeak VM for Java (Squeak VM is written in
low-level - restricted - smalltalk, which is compiled to C)
-----Original Message-----
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Friday, May 20, 2005 12:52 PM
To: [email protected]
Subject: Re: [arch] VM Candidate : JikesRVM http://jikesrvm.sourceforge.net/
Nick Lothian wrote:
>>>Why should it be so? I guess the platform dependent code
>>
>>emission code
>>
>>>is err ... not platform independent anyway. Also, if the reference
>>>platform is for instance LLVM, or some other, off the
>>
>>shelf, low-level
>>
>>>intermediate representation, then there is no more platform
>>
>>dependence
>>
>>>to take care of at the JVM level (I suppose)...
>>
>>Andy is right: "writing in Java" *above* the JVM interface
>>means you are creating bytecode and all the portability
>>efforts were taken care for you by the JVM makers. "writing
>>in Java" *below* the JVM interface means that you have to do,
>>at some point, some native code transformations yourselfs,
>>for every single different CPU architecture.
>>
>
>
> This is true, but doesn't actually seem too hard. I'm looking at the
> "arch" section of the Jikes RVM
> (http://cvs.sourceforge.net/viewcvs.py/jikesrvm/rvm/src/vm/) and the two
> architectures there (intel & PowerPC) certianly give a good starting
> point for other architectures. There appears to be an (unfinished) ARM
> backend available for it, too
> (http://www.cs.man.ac.uk/~jsinger/armrvm.html)
Ok. I admit I never looked into that part myself so I can't tell you how
hard it is to port a java VM onto another CPU architecture.
>>Writing a JVM in a compilable higher language means that the
>>compiler will do all that for you.
>>
>
> No it doesn't (unless I'm missing something). It's true you will be able
> to compile your VM on other architectures, but you still need to write
> the code generator for those architectures yourself (ie, the bit that
> converts bytecode into native instructions). In a C-based JVM you'd need
> to write that in C whereas in Jikes RVM it is in Java.
D'oh, you're absolutely right!
> JCVM has a nice feature in this area in that it converts bytecode to C
> and then lets GCC compile that. That would appear to make it very
> portable, but it isn't the way most VMs work. (Ironicaly, the C
> genetation code in JC VM is written in Java - see
> http://cvs.sourceforge.net/viewcvs.py/jcvm/jcvm/java/org/dellroad/jc/cge
> n/)
Hmmm, interesting... I wonder if we could hook directly into the
compiler intermediate representation instead of having to write a big
string using C syntax and fire a parser on it.
Does anybody know if GCC allows such a thing?
Keep in mind I know squad about GCC and friends.
--
Stefano, who should really do his homework some day.
