21–30 of 55 posts
Main author here. Let me know if you have any questions. I’d be happy to answer.
I wonder what the performance impact is. Why do young students no longer learn C? Don't you want to be closer to the underlying OS?
But the approach is to get the correct translation first, and then - if needed - bottlenecks can be removed manually. This should lead to a better migration/upgrading experience.
I wonder what the performance impact is. Why do young students no longer learn C? Don't you want to be closer to the underlying OS?
> Why do young students no longer learn C? Who said they don't? This project is about porting existing stuff, for interoperability, etc. Not as a way to "avoid learning C". > Don't you want to be closer to the underlying OS? No, why would I want to do that unless I have a specific need for that?
At least if you're using a Unix-like system, then understanding POSIX is essential for knowing how things work starting on an intermediate level.
Earlier quoted context omitted.
Thanks for the post. What was the big sticking point with the Java -> C translators?
It's easy to do a minimal prototype when doing research. But writing real translators means to get all the details right. In research we usually don't have the time for that. Translating Java - in my experience - is very hard because of the extensive runtime system (reflection, base classes, synchronization, ...). E.g. if your application does System.out.println("Hello"); you already need the System and PrintWriter c…
What do I need to do to get opensource software translated? I would like to have this http://stjarnhimlen.se/comp/sunriset.c as java code..
Please note that the software needs to be in some public repository (github, bitbucket, sourceforge, ...).
For OSS (or other projects) that just need running JVM byte code, checkout the GCC Bridge component of Renjin, which uses a combination of GCC to Soot to compile C and Fortran code to bytecode: https://github.com/bedatadriven/renjin/tree/master/tools/gcc...
Main author here. Let me know if you have any questions. I’d be happy to answer.
Interesting how gotos are translated to switches 90% of C should be pretty easy to translate, but of course, the devil (and a lot of functionality in existing libraries) is in the details. There would be probably money in translating COBOL to Java, but maybe there are solutions already?
Native C libraries (libc, libmath, ...) are just directly used from Java, not translated.
Yes, there is a lot of money in Cobol/Fortran to Java. Many tried, none successful (I know many stories). We'll look into those two languages in the future. But creating real translators takes years.
Interesting how gotos are translated to switches 90% of C should be pretty easy to translate, but of course, the devil (and a lot of functionality in existing libraries) is in the details. There would be probably money in translating COBOL to Java, but maybe there are solutions already?
There is, Proyect NACA (http://developers.slashdot.org/story/09/06/24/1915205/Automa...).
Have a look at the generated codeif you want a good laugh, it translated COBOL code to Java line by line.
This looks pretty nice. Pointer/array arithmetic seems to be handled nicely, (double)malloc(sizeof(double)*100) looks pretty ugly but it's hard to tell what's going on under the DoubleContainer hood. For OSS (or other projects) that just need running JVM byte code, checkout the GCC Bridge component of Renjin, which uses a combination of GCC to Soot to compile C and Fortran code to bytecode: https://github.com/bedatad…
malloc() we only optimized for char* so far (there are endless possible optimizations when translating C the way we do).
"(double* )malloc(sizeof(double) * 100)" should be translated as "new DoubleContainer(100, true)". We'll add that add some point.