Slashdot Mirror
Java On 8-bit Platforms
ScrotalDwarf writes: "
OneEighty software has released the world's first 8-bit Java VM. A fully functional Java VM, kilobytes rather than megabytes, in size! It's aimed at the mobile markets, but being smaller it's a whole lot faster - a fast Solaris JVM implementation!? If that wasn't enough, it's actually based on an implementation of a Turing machine.
"
including "intelligent" pens, lighting, telephones and vehicle monitoring devices.
And PAPER CLIPS!!! NO!!!!!!!!!!!!!
How much longer must these demons haunt us?
Flavio
When I was 12 (yes, twelve) my dad got me the complete set of Time/Life books on computers. I admit that to this day (20 years on) I still cast my memory back to those glossy, 4-colour pages when I make an outrageous statement about the "conservative design of CDCs and the original Crays" or the "inherent, uh, complexity I s'pose, of vector processing, uh, chips? architecture?"
anyhoo, that von-neuman/turing article looks a heck of a lot like a photocopy from that time/life book.
hm.
2 1337 4 u!
The press release also makes some extremely dubious claims about "a novel architectural approach that allows the creation of extremely compact software, often many times smaller than that built using traditional coding techniques." Uh-huh. It's magic!
The 180sw web site says that this is the first 8-bit Java VM. That's definitely not true -- TinyVM for Lego Mindstorms has been around for quite a long time, and I doubt that's even the first. This "GENEVA" thing may be more complete, but that's a different issue.
--
Two reasons why we still have, and probably always will have 8 bit chips:
Cost : 8 bit chips are cheaper to make.
Power Consumption : 8 bit chips use less power.
I can see no reason why a simple, non-scientific calculator would ever want to use a 16 bit chip. It would cost more to make and require a larger solar panel. What's the point? There are more 8 bit chips out in the marketplace then any other type of chip and this isn't going to change any time soon. Eight bits is hardly useless.
Willy
Okay maybe a little bit: have you ever designed a Turing machine from scratch to do something as simple as multiply two numbers? It's incredibly tedious. There's a reason we invented more complicated instruction sets, and then higher-level languages.
--
In general, it takes more bits of memory to implement a function on a Universal Turing Machine than on a conventional microprocessor. The point of the UTM wasn't that it was efficient, it was that it was a very simply machine that could compute anything that is computable. But not necessarily very quickly.
I hope the managers of the funds my 401k is invested in don't invest in companies like this; do they have experts to evaluate high-tech startups?
Comment removed based on user account deletion
The Church-Turing Thesis is the preposition that any discrete function can be solved by symbolic manipulation. A Turing Machine is defined as a device which can solve a computable function by means of symbolic manipulation (like 1s and 0s, for example). (A Universal Turing Machine is a machine that can emulate any Turing Machine, and can therefore solve any discrete function.)
Basically, this means every computer that operates by rules of logic (AND, OR, NOT, etc, as opposed to chaotic or fuzzy systems) is a Turing Machine. Your desktop PC, your Nokia, your calculator watch, your Chinese water clock, are all examples of Turing Machines.
Personally, I'd be far more amazed by a JVM that was implemented by a device that was not a Turing Machine.
Kevin Fox
Kevin Fox
I guess he had problems convincing people to program in Forth, because now he has a Java front end.
I have written a truly remarkable program which this sig is too small to contain.
Furthermore, Turing machines are extremely unpractical computing devices. They are not allowed to have any kind of I/O during computation. All input must reside on the tape at input, and any output must be written to tape before termination. I think such a view of computing would be one of the most useless things ever to use in embedded computing where side-effects is usually all that matters.
Now, there are ways around these limitation, such as using more than one tape which can often reduce a Turing machine design dramatically. But these reductions are usually only conceptually. If you take the time to write up all the state-transitions and so on in one large table as you eventually will have to, if you are to implement it in software, it doesn't really matter. There is also the concept of an Oracle Turing Machine, where you could have special states, and if the machine decided to enter one of those states, magic would happen, and the tape would suddenly be changed in accordance with the procedure associated with that state (e.g, a special state for multiplication of two 32-bit numbers). It could also be used as a way to fake polling I/O. But it still would be nowhere as convenient or practical as just doing normal assembly programming.
I'm not sure what they are trying to get us to believe here. Ok, they've made a small Java VM (only 5 times bigger than TinyVM). They do, however also claim to have revolutionized computing by reinventing the Turing Machine. Given the lack of technical details on exactly what this means, it's impossible to know whether it is correct. But, considering the alternative of a hoax, marketing madness, or some other unknown reason for them to mislead us, I find it hard to believe that it can be true.
If you have an AMEX "Blue" card, then you have a JVM in your pocket (I believe its an Hitachi H8, but one of the tiny 8 bit versions).
About half of all smartcards made right now (including almost all from European giant GemPlus) run JVMs.
Anyone who went to Sun's JavaOne show a couple of years ago was handed a rather chunky ring, which had a Dallas Semiconductor iButton on it - this too has a JVM (I actually wrote some code for mine - using the same toolchain as for regular desktop java). I believe it is an 8051 microcontroller.
I just received a TINI board from Dallas, which is the same as the iButton, but in a DIMM form-factor. It's sooooo cool. Info about it is here
Maybe someone should code a 4-bit JVM, so we can run it on Voyager 2 (which has two 4-bit processors) - how's that for mobile code!
Oh yeah, their software runs faster if nobody knows how it works or is allowed to observe it. Sounds like some kind of quantum computer, huh? More like an investor scam.
Looks to me like the old codger in charge is trying to exploit the good name of Alan Turing, his former co-worker. So where was he when Mr. Turing was on trial and needed a character witness to testify about his outstanding contributions to computer science and the defeat of Adolf Hitler?
(It's so rare I get the chance to use a legitimate ad swasticum attack.)
After that pedantic lecture on Turing machines, this vaguely reassuring "theoretical" answer does not impress me. The lack of speed may not seem "problematic" to an academic who doesn't know anything specific about game programming. But how about answering a more specific question: "For the practical programming of even simple computer games, is ORIGIN any better than Java, which totally sucks ass?"-Don
Take a look and feel free: http://www.PieMenu.com
The Java byte code really isn't all that slow. In fact, making the VM smaller would actually probably make it slower since you'd be leaving out things like a JIT or any sort of optimization. Generally speaking, there is a compromize between speed and size - large usually is faster (optimized for speed), smaller usually is slower (optimized for size).
The JVM itself is a nice speedy little thing. It's not slow. It's the Abstract Windowing Toolkit (AWT) that's slow! Since almost all Java apps require some form of GUI interaction, and the AWT is the means of graphical interaction, the AWT becomes a signifigant bottleneck. If Sun spent some time on speeding up the AWT, all those pretty graphical Java apps would receive a nice speed boost.
Even with the JIT turned off, Java bytecode alone usually runs at a decent clip. Unfortunately for Java applications, the AWT is very slow - it actually became slower in JDK1.2 and is picking up some speed in JDK1.3 (it hasn't regained it's JDK1.1 speed though).
If anyone wants to read a more indepth benchmark comparing x86 C with Java code, try here.
You are in a maze of twisty little relative jumps, all alike.
After reading all the white papers, I was able to draw out some facts:
VM is supposedly 70k, supports multi-threading and GC. No graphics capability however. I wonder how big the Palm KVM is at? It includes a small implementation with graphics.
Compatible with Java 1.3 as far as class file format goes. Supposedly runs can interpret any Java bytecode.
The VM itself is called Geneva, and runs on an engine/system/framework called Origin.
Origin itself is composed of small building blocks with a "high dehree of reuse". An interesting twist is that while of course they wish the internal blocks (procedures) to be closed, they encourage outside blocks to be developed and will pay royalties to the developer of these outside blocks if they are incorperated into the core.
Right now, it appears to work on x86 chips and Sparc chips - the Origin system itself must be ported to other platforms, and then Genevia will run on top of it.
Origin itself has some sort of primitive internal database/file system, and they talk of perhaps working with DB companies to improve on that.
You can write directly in Origin if you like, but there is no kind of IDE or the like - they encourage use of the Genevia Java VM as an easy path to using Origin.
It sounds kind of interesting. What they need to do now is release it for the Palm.
"There is more worth loving than we have strength to love." - Brian Jay Stanley