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.
"
Seriously, this may not be the most important article on Slashdot, but it is an important advancement. Being able to have Java on your cell phone actually serves some purpose (as opposed to a few other things cell phone makers have come up with). It allows just about anyone to put whatever they want onto their cell phone at little / no cost. The downside: M$ starts making cell phone programs and your phone crashes in the middle of a conversation (it doesn't disconnect, it doesn't drop the signal, it gives you the LCD screen of death).
OTOH, what's the point behind the Turing machine basis?
It's all about the Karma Points, baybee...
Moderators: Read from the bottom up!
SIG: HUP
Finally java comes to my NES and Sega Master System! Now I can .... do nothing more than I previously could.
This Wiki Feeds You TV and Anime - vidwiki.org
including "intelligent" pens, lighting, telephones and vehicle monitoring devices.
And PAPER CLIPS!!! NO!!!!!!!!!!!!!
How much longer must these demons haunt us?
Flavio
The referenced paper is a little slim on actual technical content. It appears that what they're proposing is in effect an extensible bytecode (what they refer to as "adding new procedures"). This would not in itself be novel---it's one of the guiding principles behind Forth, which is one of the reasons Forth is still used for resource-constrained portable coding. There does seem to be provision for stuffing all those new bytecodes into a single namespace.
Not surprising, but it will be encouraging if they succeed in getting a fully functional system in a truly small footprint. More power to them. But it'd be nice to see more detail on what their tools are _really_ doing.
-Jan
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.
--
According to what I've read, I think the 2600 was an 8-bit system. It had a Motorola 6507 CPU, which was a modified 6502. The 6502 was an 8-bit processor with a 16-bit address bus. The 6507 was the exact same processor with two modifications -- a 13-bit address bus and it had no interrupt lines.
J
The referenced whitepaper is kind of a POS. They claim that with 26 kilobytes of operating system, it's possible to implement any solution. That's fine, but where are the drivers for the video card going to come from? Where is the sound going to come from? Where will the drivers for my funky backup drive reside? They will all have to be tacked on to those 26 kilobytes of memory allocation and printing to the screen, and the result is going to be a system just as large as anything else out there, once you add all the actually useful stuff. Besides, Java is only useful when it has some windowing libraries and the like, those still need to be built for each cel phone or whatever device that the stuff will go on. I don't think that something can really be touted as a Java implementation unless a large majority of the libs (javax.swing.*, etc) also exist. If you can't run StarOffice on your cel phone, what good is it?
-S
I'm not sure exactly what they're claiming but the TINI board has run java on an 8 bit processor for some time.
Before long, the paper clips will take on the task of organizing all of those toasters running Linux into a formidable army. I'd bet that they take on the people who eat Pop-Tarts and bagels cold first... it's people like that that are driving toasters to oblivion.
Viva la revolucion!
--Psi
Max, in America, it's customary to drive on the right.
Turing completeness is not a lofty goal for an instruction/programming system. You'll find Turing completeness in the strangest places - theoretically I can produce any computable result with TeX macros.
Another contender for "first 8-bit Java VM" is Dallas Semiconductor's collection of embedded Java devices at www.ibutton.com.
There's some neat stuff, like the "tini" board - a small (68-pin SIMM form-factor) embedded computer with 10BaseT ethernet and TCP/IP networking. It can run a web server, as well as Telnet and FTP. It also has a couple of serial ports for interfacing to other components.
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?
...I can finally get Java running on my NES?
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Comment removed based on user account deletion
Lately it seems like people complain about how impractical certain achievements posted on Slashdot are. I was under the impression that in the eyes of fellow geeks, hacks stand on their own merit - being judged on how clever they are and nothing else. When did all this concern about how useful or practical an accomplishment is factor into the equation about whether it deserves recognition? (ex. a Slashdot article). Java on 8 bit machines is an extremely cool hack - inter-geek approval where it is merrited - if they want to try and make a living off this hack, that's their business (and their investors' I suppose).
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.
Good grief! That means that you could implement this in my favorite language Brainfuck. []!
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!
I'm not an expert, but I believe there are also real-world computers (at least theoretical ones) that are more powerful than a Turing machine, e.g. quantum computers.
Find free books.
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
Okay, so it's an 8-bit Turing complete machine. Many text editors, such as VI are complete but you ain't gonna see me playing Quake on them...
Yeah, it's nice for Java, after all, the more machines a VM can run on, the better for it. Unfortunately, the white paper reads more like marketing spiel rather than anything else.
If he had a point to make at all, it's that too many programmers don't write code with a view to reusability in mind. Now that is something worth reminding us...
Amazed at how many posts have been moderated 0 in this topic...
"A goldfish was his muse, eternally amused"
Vs lbh pna ernq guvf, ybt bss abj. Tb bhgfvqr. Syl n xvgr.
So what if the folks at one80 have a flawed understanding of a turing machine. So what if one80 is using FORTH to get it done. Their claim is that they have a full 1.2 compliant, not just personal java, implementation that is tiny. Pretty cool.
Wow maybe they can "backport" this to my 32 bit machine, so I can finally run java faster than paint drys....
(+1 Funny) only if I laugh out loud.
Although the white paper cites FORTH, it fails to demonstrate any substantative difference between its architecture and that of FORTH. Granted, my knowledge of FORTH is a little hazy, but this seems awfully similar (in fact, interpretive Java VM's are stack machines as well.)
;-}.
My understanding of how FORTH works is that each opcode is a reference to a subroutine. All subroutines implicitly read their input off the stack and leave their output on the stack. I think even conditional execution is handled in this way. There is no real difference between system routines and "user" routines, and traps to the underlying architecture are just a specific instruction that takes the jump address off the stack.
FORTH code could be extremely compact, because the source and destination of operands and results were implicit and did not have to be coded in the instruction. A FORTH interpreter could also be very compact because the underlying architecture is very simple. A friend of mine once (late '70s) implemented a data logger in 2K of ROM by writing a FORTH interpreter that took about 30 bytes and implementing the rest in FORTH. This was done on a COSMAC (used an 1802 processor - the machine with the SEX instruction).
Java VM's (I think) are a stack machine also, and java bytecode is quite compact for much the same reason FORTH is. Users of swing may not believe this but that's a different rant
Turing machines had random access storage in the form of a conceptual tape that the machine could seek back and forwards along. Hodson's white paper talks about stacks (as used in FORTH and various non turing-complete automata) but appears to refer to his VM as using a stack. I can't really see much difference between this and FORTH. Perhaps I am exhibiting high specific gravity but the parallels between this VM and a turing machine seem pretty strained. He doesn't really talk about the "stack" on this machine being random access, and I can't really see how this would help beyond the mark, dup, roll etc. operators that FORTH VM's have anyway. (Note to self - Can't actually remember if FORTH does marks on the stack; I might be confusing it with Postscript)
To save me having to trot down the road to Borders and buy the java VM spec, could someone who understands the architectures of Java and FORTH say something cogent on the differences?
Roger Penrose is perhaps the latest of a long line of individuals who have argued the brain has powers beyond a Turing Machine. Despite his claims, the jury is definitely still out on this.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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.
You can also store data in the state of the machine, instead of writing it on the tape. Turing machines don't have registers, nor stacks, nor random access memory, but they can be in any number of different states. So to do anything non-trivial, you end up with a heck of a lot of machine states, connected together in a complex network. In order to copy a number, you have to suck up some of that number into the machine state "temporary storage", then go into a state that moves the read/write head to the destination while remembering the temporary state, and then go through a series of states that writes the machine state out onto the tape while moving the head. So you could write a program that copied a number one bit at a time by moving back and forth between source and destination, using relatively few machine states. Or a program that copied numbers more efficiently n bits at a time with 2^n and then some machine states. To do anything non-trivial, you end up with zillions of machine states, representing a network of all possible values of temporary storage connected by tape seeking and writing instructions, and you also require infinite amounts of tape to execute the program.
Think of it like an Adventure (MUD) game with one deterministic player, who is carrying a tape and read/write head. The state of the machine is which room you're in, plus the state of the tape and position of the head. Each room has a door labeled for each possible token on the tape, and when you walk through correct door, it can write a token on the tape, and move the head up or down. A program is a set of interconnected rooms. You have to double the number of rooms (states) to represent one bit of information in the machine state, like the Star Trek episode when they were beamed aboard an exact duplicate of the Enterprise, that represented one bit (the answer to the question "Is this real?").
It's hard for me to believe that they're using a Turing machine model for efficiency's sake.
-Don
Take a look and feel free: http://www.PieMenu.com
A few years ago, I heard that C-64s were still in production for sale in either Mexico or China, where PCs were too expensive for the general public. Not sure whether that's the case now, with the abundancy of cheap Pentioid PCs.
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
Sorry. You've got Turing Machines and Universal Turing Machines confused. Any device that can complete even a single function via symbolic manipulation is by definition a Turing Machine. A device that can complete any computable function is a Universal Turing Machine.
Kevin Fox
Kevin Fox
It has been a few decades since we have had to think seriously about making things small. It is a fine, albeit a lost, art. News flash: you make code small with embedded interpreters. Threaded code, microcode, internal data bases and so forth are the meat and marrow of coding tiny. An extensible VM or bytecode interpreter as a vehicle for making code small isn't news either -- that was the fundamental operation of threated interpretive languages such as Forth. These are great, difficult and fun things to do. But, alas, nobody has really much use for this sort of thing anymore. Every now and then, we need this kind of thing again. But coding for 8-bit machines? Why?
OK, 8-bit processor instructions are 8-bit, and 32-bit instructions are 32-bit. Moreover, memory pointers on 8-bit systems are normally 16-bit (relative and zero-page pointers are 8-bit), and on 32-bit systems they are, well, 32-bit (rel. and 0-page 16-bit). With 1-byte alignment, data structures are as big on 8-bit systems as they are on 32-bit systems.
;-)
;-) for its simple tasks. Then again, this makes me wonder why a wrist watch needs Java; it doesn't really benefit from "run once, compile everywhere" code[*], the only thing that really matters to such a watch is how it communicates with the outside world. Well, maybe system updates... I don't know. I just don't yet see the use of my fridge talking in a 4gl. He can just use compiled-to-machinecode programs as far as I'm concerned. Then, if it's an 8-bit processor, the program itself will be about 1/4th of a 32-bit program, and the VM will be 0 bytes.
;-)
So the VM might indeed be shrunk a lot, say it may become a little more than 1/4 of its original size if you put it on an 8-bit system. This would be a nice rate for any "embedded" program.
Alas, the VM is not the program. It simply is the VM. The program is written in "run once, compile everywhere" code[*], so this code has the same size no matter where you put it.
And I recall the class libraries are something like 20 Mb of code. And while an embedded program might just not require, for instance, Swing, it is part of standard Java AFAIK. What I am trying to say is that programs expect the standard class library to be there, so it'll cost you 20 Mb of space anyway. To set up 20 Mb of space on an 8-bit machine, you would cross some 64k boundaries
One solution might be to get rid of the class libraries, and write the code yourself, or "statically link" the code. This makes your program bigger...
You might argue that e.g. a wrist watch wouldn't need class libraries (e.g. Swing
While I'm talking about this, does anyone know how many bits a single Java instruction is?
[*] OK, I wanted to write "compile once, run anywhere", but this appeared instead. Given that much Java VM's are Jitter-based (compile to machinecode on the fly), I actually think that this typo isn't that goofy
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
When I first heard about embedded java I put it right with WinCE in the "Why?!" catagories. I believe that java is a pretty good RAD language and it is nice to have a web enabled platform independent gui standard. These are its strengths and they are great for web programs where bandwidth is often the limiting factor, not code spead and control. Put more in the VM and make the code that is moved about smaller. Let someone write to one gui standard.
In the world of gigabit NICs and FibreChannel RAID controllers running on InfiniBand, java just doesn't fit. Sure you can take a chainsaw to it and cut out what you don't need. This isn't java anymore though. If it doesn't run all the sun APIs, it isn't java. Now if sun starts bending on that for publicity and cash ("How much does a java logo cost?") than they look real hipocritical considering their battle with MS.
Even with a chainsawed java, it still doesn't make sense. Java has no stack structures except for primitives. It gives the author little control of memory deallocation. This is a big issue when you have limited amounts RAM and no swap. Also, having "secret" threads running around freeing memory while the author needs code to run at a specific rate really hurts. Graphics? What does an anti-lock breaking system need with graphics code?
I suspect there is reason that most embedded/realtime OSs are written in C/assembly and have those types of APIs. Even C++ is feared due to sense of lack of control. The STL is never used without source control of it. At these levels programmers are pulled back to the days when size and speed really mattered. Java can't give you that. A JVM takes up too much space in software and java chips are often too big, require too much power or are too expensive or all of the above. I suspect that JVMs in an embedded environment would find it hard to achieve C/assembly speeds. In the gui feature rich world it doesn't matter that much. In the world were the two major features are send and receive, size and speed are king.
-- soldack
Again, Turing Machines aren't simulations. A pocket calculator is a real, honest-to-whatever, Turing Machine. No simulation about it. It can solve a problem via symbolic manipulation. Bam: Turing Machine.
Universal Turing Machines are simulations, because of the infinite tape (and time) needed.
Kevin Fox
Kevin Fox
see subject.
Can your IM do this?
You already can build a native Java chip. You just build your hardware to do what the JVM specs say a JVM needs to do and you're set. Using the Transmeta code morphing shit is just going to slowdown the process. Running a JVM on a chip with code morphing is running bytecode in a virtual machine inside of a software emulated ISA. Your best bet for using Transmeta chips would be to compile the JVM into the VLIW format and just run it natively on the TM chip. Code morphing is just a trick they came up with to let x86 run on their processor without their processor actually being an x86.
I'm a loner Dottie, a Rebel.
C wasn't designed for game programming back in the day. It could be fairly slow and you ran into problems sometimes. Then it got really refined and well understood and what do you program games in now? Oh yeah thats right, C and its legacy. Because you'd have problems writing a 3D shooter in Java right now doesn't make the language suck ass. A couple years ago you couldn't write a 3D shooter in any language.
I'm a loner Dottie, a Rebel.
Zork and all the other early Infocom games used a VM (called the Z-machine) to run their games on 8-bit platforms. This VM spec is still used today for new IF games. Also, the Apple ][ ROM had an interpreter for performing 16-bit integer math calculations, called "Sweet 16". Applesoft itself was interpreted, like many other BASICs.
The white paper is a crackpot spewing about "state of mind" and "genomes" and trying to appear academic. If he has any new ideas, I'm not able to penetrate the BS to find them. Turing machine == Von Neumann machine == any calculating device, so what's new here?
If he was posting on USENET he would be using ALL CAPITAL LETTERS for certain KEY TERMS that expressed his REVOLUTIONARY IDEAS.
Doesn't the use of loops and functions to quicken the job of programing actualy slow down the process? for example... for a = 1 to 100 print $getline(a) increase A next a would be slower than... print $getline(1) print $getline(2) print $getline(3)...etc I would think not having to process the extra increase, and the if would speed it up. but also increase the size of the end program.
Looping code can improves a program's use of CPU cache. In your second code example, huge loops would require many sequential code pages to be paged in from disk. Much more expensive than saving a i++ loop counter..
cpeterso
Neat stuff but ... it still doesn't address two big issues:
1. On most platforms stack memory allocate is much faster than dynamic. As far as I know, Java does not support allocating structures on the stack.
2. With limited resources, programmers need tight control over memory deallocation. While you can force a call to the GC, it is usually not a synchronous call. Sometimes you need to know all the memory from step 1 is free before going to to step 2.
A bit about this paticular JVM. It does not support 64-bit data types. 64-bit PCI, PCI-X and Infiniband all require 64-bit addressing. That makes this unusable for most I/O adapters unless this JVM supports 64-bit addressing with its references types but hides it from the user.
Oh well...
-- soldack