Tapping into large software base = C/C++ to Java compiler?
Submitted by lex on Wed, 05/30/2007 - 22:03.
From the global point of view:
The amount of software written for Java is much less than for C/C++. There is also a large base of free software written in C/C++ for Linux systems.
Having a C/C++ to Java compiler would allow JNode to compile the required C libraries into Java bytecode and then compile and use all the mentioned software. That would give an incredible kick-start to the operating system as whole, because the OS is only as good as the selection of software you can run on it.
While it is my understanding that everyone at JNode is Java enthusiast and would rather promote developing software in Java, I have to ask the following question...
Out of curiosity and from purely hypothetical point of view:
Have the C/C++ to Java compilers been considered for JNode? (under the assumption it is possible to create such a compiler).
- Login to post comments
GCC bytecode backend at odds with RMS
The problem is that, according to an old discussion with RMS
java bytecode considered bad
the GCC bytecode backend was supposedly discontinued, deleted, nowhere to be found etc.
I bump into this post recently because I was looking into a quick and dirty way to get rid of some JNI stuff in my system (moving from 32 bits to 64 bits... you get to love Java even more when dealing with old C code and porting issues). The only "accepted" solution is to use the MMIX GCC backend. I got the cross compiler to work and the MMIX interpreter took a small "performance hit"
---from 89s to 2h--- so I didn't further "investigate" whether running the MMIX interpreter in Java was going to be slow. I guess the idea would be to compile the MMIX into bytecodes, but MMIX is a 64 bits architecture and the JVM isn't.
"java bytecode considered bad" - is it still so?
I've just read the email discussion you mentioned and I think that RMS might have an other opinion today.
His reasons for rejecting the GCC bytecode backend were purely political and generated by the licensing model of Java in that time. However things are different today, Java is open source under GPL and technically a GCC Java bytecode backend is as interesting as it was back then while there are no licensing issues any more.
I hope that the really radical words of RMS didn't kill that technically really interesting project completely otherwise a new GCC bytecode backend will have to start from zero again.
Regards, Levente
Hi Levente, I also hope RMS
Hi Levente,
I also hope RMS didn't kill the project. His clear censorship seems to clash heads on with all the Freedom as Free Speech behind the FSF PR.
I re-read the post and I still don't see how SUN compiler being GPL changes RMS fears: a private company could still package an "improved C compiler" packaged as
C code -> GCC with Java Bytecodes backed -> Propietary Bytecode optimizer -> GCC with Java Bytecode frontend -> Optimized Platform-dependent Binary
basically circumventing the GPL in GCC and selling a product based on GCC, clearly undermining the goals of the project.
These are clearly political goals but you mention they might be generated by the Java licensing model at the time. I'd like to hear more about your opinion in the subject.
Best regards, pablod
appreciating idea
hi lex,
welcome here.I appreciate U for ur idea.
but,as according to Peter,we need to be more concern with our VM core
Bugs.first of all have to reduce memory usage.and also use more
fine thread handling than now and have to make it faster.
but,no problem, you can get into it, and may contribute codes in it.
GOODBYE...
from Swarup(boss)......
Compiling C/C++ to bytecodes is hard
The problem is that C and C++ are based on the model that a program can access any memory cell, and can cast between pointer-sized scalars and pointers at will. This is fundamentally at odds with the execution model defined by the JVM.
So if you wanted to execute a C/C++ program under the JVM, you would need to create an interpretter that emulates the C/C++ memory model. The result is bound to be slow. You might consider building a compiler that performs deep semantic analysis to (for example) translate C-style pointer arithmetic into a "safe" bytecode equivalents. However, I suspect that the analysis is equivalent to the Halting Problem; i.e. that it would be proveably impossible in the general case.
Another issue is that most interesting C/C++ programs depend on extensive libraries which (at some level) interface with the host OS. So, before you could run a bytecode-compiled C/C++ application you'd need to port the libraries.
C/C++ to Java tools
Ephedra http://ovid.tigris.org/Ephedra/ creates Java source code that emulates the C/C++ memory model. It generates Java code that allocates one huge array, and then all memory access is via that array. As you might imagine, the generated code is about as readable as byte code.
Jazillian, my company, http://www.jazillian.com, translates C/C++ to Java source. We have a very different approach than all the other tools. Our approach tends not to work well on low-level code such as what you want. Also, it's a commercial service, and we don't (yet) offer anything free.
Contact me directly if you have questions.
Andy Tripp
You're actually not the
You're actually not the first one proposing to use existing C/C++ sources, and we also did allready think about it.
Current software would be JPC which works in JNode and is a nice project, thought is is a complete PC emulator. The other software I investigated on is PearColator, it is "more promissing" for what you're talking about.
So why aren't we using it? Because first of all, emulated/virtualized apps are allways slower than "native ones" (if I may say that for java
). You need much more memory for emulated C/C++ because you need a way for memory separation (no mmu for JNode) and at some point (e.g. libraries) you will interact with the hardware. So you need for everything a wrapper.. e.g. a complete POSIX interface or something like that.
Imho the main deficit of JNode is, that it is far from complete at API and kernel level, it has still core bugs that make JNode die from time to time (and perhaps the current speed of JNode).
And if you look around there's mostly for anything a java replacement, and once JNode is finished the missing parts will be there too
So to summarize, C/C++ emulators are a nice idea, and surely interessting to try it in JNode, but at least for me, there's no need to have it as a "core" component of JNode. Anyway our main goal is to run "Any java application will [..] on it, fast & secure!" (from our main page
)
Everyone is Welcome
hai
it is not a metter that shows us the Jnode is only for Java and others not.Jnode is typically different in its Execution Model and other lower level concepts of a OS.But, we all want to run all types of programmes in Jnode based Platforms.Like Jython etc curently running in JNode.If we can create a C/C++ to ByteCode compiler then we can use the C/C++ Softwares also in JNode.
But, if the softwares that is now in C/C++ if can rewrite by Java.Then, its bytecode creation is now more easy because we have the SUN's JDK now instant.
But, we have a broad view for support all platforms like .NET,even C/C++ for JNode obviusly.
Thanks
Tanmoy Deb