[Michael Kohn] sent in a link to the set of projects he’s been working on lately. The Java Grinder is a project that converts Java code for use on microcontrollers. This actually started back in 2009, when he mentioned that the project was worthless because there were already a ton of Java virtual machines out there. But if he had really thought that he’d never learn anything. We’re glad [Michael] picked this back up and made something out of it.
The image above shows the proof of concept. It’s a box bouncing around the Nokia 6100 screen. He wrote the animation in Java, and used his grinder to turn the code into dsPIC assembly, which was then compiled and flashed onto the microcontroller. That’s not all, he’s also coded a Mandelbrot set generator or the same hardware. As it stands he can also produce assembly code for use on MSP430 chips.
This kind of exploration is great for the brain. We see it as a natural extension of the learning you acquire from Nand2Tetris which walks through the essential text The Elements of Computing Systems. If you’re not familiar, that’s a trip from building your first logic gate, which you plunk together with others to build an ALU, then start coding all the way up to a virtual machine to run on your simulated hardware.
Video of the bouncing box and Mandelbrot set is below.
13 thoughts on “Java Grinder Spits Out DsPIC And MSP430 Assembly Code”
Nice! I’ve got to try this out.
Isn’t this called a compiler? Java is a language and all languages can be compiled to assembly.
Yes and no.
Technically Java is not compiled, it is /interpreted/. Compiling suggests that the language is parsed and converted into object/machine code (assembly). Java is converted into /bytecode/, which is a step between the language and native assembly. This bytecode is then what gets executed at runtime by making use of a Just In Time (JIT) compiler, that compiles the bytecode on the fly during execution. This is why Java is so portable. The bytecode is exactly the same regardless of platform: x86, x64, i64, SPARC, ARM, PowerPC and all the others. You just need a JIT Compiler, or in Java’s case, a JVM/JRE that is compatible with the machine that you are running on and you are good to go!
Now, in the case of the project mentioned here, from what I gather he created a device that converts the Java bytecode into the correct assembly for the chip used. So technically, yes it is a compiler. But only the software on the device is the compiler, not the device itself. It would’ve been easier to to the whole exercise on his computer, building and converting into PIC assembly on one machine. But now he has a standalone device that he can plug into any computer with the JDK and he can program for his PIC.
“A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language”
There is no requirement that compiler translate to machine code to somehow be considered a compiler. There are language to language compilers and language to Virtual Machine compilers (like you see with Java, et al).
We should also draw a distinction between Java the system and Java the language. Java the system (as created by Sun and managed by Oracle) compiles to Java bytecode; but there is nothing inherent in Java that requires it to. GCJ compiles to native code, back in the day Dinkumware sold a Java to C++ compiler, for example
1. “Technically Java is not compiled, it is /interpreted/.” No it is compiled to a byte code not to a native ISA but it is still compiled.
2. “Java is converted into /bytecode/, which is a step between the language and native assembly.” It does have to be be compiled to byte code see http://gcc.gnu.org/java/. It is even possible to compile the bytecode into a native ISA and not just at run time.
Any programing language can be compiled or interpreted. I worked on a system with interpreted Fortran, Cobol, and Pascal. Pascal was first compiled to a byte code called P code and later native compilers where created. Basic started out as interpreted but has been compiled as well for a long time.
Saying Java is “compiled, interpreted, or runs on a VM” is must not true. Any programing language can be compiled, interpreted or run on a VM. You as many people do are confusing the implementation with the language.
Reminded me of: http://www.youtube.com/watch?v=SmFEK2gq4QQ
Whats next, G-code to MSP430 asm? What about Flash ActionScript?
Can’t wait to see the next useless compiler/converter/whatever.
I dunno… My enjoyment level usually increases as the usefulness of the project decreases.
We always joke about a Powerpoint to HDL (or language of the day for the software type) compiler at work as that’s what our requirements specs from the marketing types at Mount Sinai (or Cloud 9)…
It is a compiler called “Java Grinder”, but yes, it is extremely odd that the word compiler did not appear anywhere in the writeup. HaD should hire some native English speakers.
Or they should hire technical writers…
I’m thinking it would be more useful if it converted to C, so it could be further compiled to run on any target machine. Although that might make it less cool, or fun to write.
Java_Grinder is a compiler, not a JVM. However, you can make your own Java API for a particular platform, and have an easy time programming that platform. Check out the c64 demo for a crude example:
That demo started as bytecode from the standard Java compiler, and was really easy to make. As long as the API’s match, one could even target different microcontrollers from the same code base just by changing an import. Some processors (such as MSP430) are optimized at the register level, enabling programs to run as fast as possible.
I hope this helps to explain the concept and usefulness of this program.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)