Klaus D. Witzel wrote:
> nice find, perhaps they learned the eToys name from the OLPC project ;-)

This is a rather obvious name - I remember two companies fighting over
it back in the .com era.
 
> Question to the VM guru: are there any opcodes in the instruction set of  
> ARM9 which allow a *fast* VM? A *small* VM is addressed by the thumb  
> thing, IIRC. But what about speed. And what VM technology, (direct)  
> threaded bytecode, or what does ARM9 support best.

This chip has the Jazelle 1 technology, which is unfortunately hardwired
for Java. The most common bytecodes get translated on the fly into a
single ARM instruction (just like Thumb) while the more complex ones
trap into a software implementation. An equivalent circuit for handling
Squeak bytecodes would be fantastic.

Though it lacks the register windows I like so much, the ARM has been my
favorite RISC instruction set since I studied it 21 years ago. Only in
the last couple of months have I been able to come up with something I
feel is nicer (http://www.merlintec.com:8080/Hardware/RISC42). Two
things that make the ARM great for implementing stuff like Squeak are
the ability to use shifts and rotates with every instruction (allowing
up to four registers to be specified instead of just three) and the
ability to conditionally execute any instruction. The latter reduces the
cost of doing quick stuff like clearing tags.

Bert Freudenberg wrote:
> The most severe drawback of ARM is lacking floating point support.  
> That's one of the major reasons OLPC went with the Geode and not ARM.

That is the official story, but I would guess that the fact that AMD was
funding the project was a more important reason. Consider the ARM7500FE
from the late 1990s, for example (click on "features"):

http://www.cirrus.com/en/products/pro/detail/P940.html

Its hardware floating point implementation was a good match for its
integer performance (both very weak by today's standards). The truth is
that most ARM customers don't care about floating point and so most off
the shelf variations don't include it. Though OLPC had a minimum
projected volume of tens of millions and is an extremely cost sensitive
project, they decided early on to limit themselves to chips that were
already in use in other high volume products. This meant they would
avoid any components just being launched and would not design any chips
of their own. With that limitation then floating point is indeed a
problem for the ARM. But in the end they had to create two custom chips
for the project (display controller for the special LCD and the camera
and flash controller).

Alex Perez pointed out this very cool variation of the ARM that will
soon be available in production quantities:

> http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX31&nodeId=01J4Fs2973ZrDR

The vector floating point unit seems like a great option which Squeak's
FloatArrays could easily be patched to take full advantage of. In
contrast the Geode's floating point performance turned out to be only
about half of what the OLPC people originally had thought it would be.

-- Jecel