Alan Kay wrote: > In the "difference between research and engineering department" I > think I would first port a version of Smalltalk to this system.
The Squeak VM used in the new OLPC machine should work just fine on this board on top of one of the Linuxes that have already been tested on it. It probably will be half the speed of the OLPC XO 1.75, but I expect it to be very usable. > One of the fun side-projects done in the early part of the Squeak > system was when John Maloney and a Berkeley grad student ported > Squeak to "a luggage tag" -- that is to the Mitsubishi hybrid "computer > on a chip" that existed back ca 1997. This was a ARM-like 32 bit > microprocessor plus 4MB (or more) memory on a single die. This plus > one ASIC constituted the whole computer. I had meant to mention this project in my previous post. It was briefly mentioned in these pages: http://wiki.squeak.org/squeak/5727 http://sib-download.ddo.jp/~sib/Squeak_World/Squeak_Swiki/271.html (this link didn't work for me today) A similar effort used the Hyperstone chip: http://wiki.squeak.org/squeak/1836 > Mitsubishi did this nice system for mobile use. Motorola bought the > rights to this technology and completely buried it to kill competition. Actually, a company called Renesas sold this chip for many years. But I have just checked and their version lacks the large embedded DRAM and only has the typical memory of a high end microcontroller: http://www.renesas.com/products/mpumcu/m32r/index.jsp > (We call it the "luggage tag" because they would embed failed chips > in Lucite to make luggage tags!) Cute! I was interested in doing something like this with working chips to have a part children could use to build their own computers, even if they dropped it on the floor and the dog chewed on it a bit. By having the bare chip visible (even if not very clearly), it would seem a little less mysterious than normal electronics. > Anyway, for fun John and the grad student ported Squeak to this bare chip > (including having to write the BiOS code). It worked fine, and I was able to > do a large scale Etoy demo on it. > Although Squeak was quite small in those days, a number of effective > optimizations had been done at various levels, and so it was quite efficient, > and all plus Etoys fit easily into 4MB. The Squeak that David Ungar and friends are running on the Tile64 chips uses a 2MB image in order to fit entirely in that chip's level 2 cache so that they don't have to deal with access to the external memory. > In the earliest days of the OLPC XO project we made an offer to make Squeak > the entire OS of the XO, etc., but you can imagine the resistance! I only learned about this in 2009. Back in 2005 I tried to form a group on the squeak-dev list to put Squeak on that machine. Nobody showed any interest, so I wrote offering to collaborate but was told that they didn't need my help because you and your team were already working on it. At the time the argument about the relative size of the Python and Squeak communities made perfect sense. And L. Peter Deutsch was then working on a real VM for what had become his favorite language: http://marginalguesswork.blogspot.com/2004/08/you-dont-tug-on-supermans- cape.html In retrospect, I feel it was a mistake. Everyone who is coding in Python for OLPC and Sugar learned the language for that project. The Python community is mostly unaware of these projects and have not helped in any way that I have seen. If the money and effort spent on Sugar had been spent on cleaning up SqueakNOS and Morphic/Etoys instead I think the result might have been more interesting. But all the technical people were Unix guys and Red Hat and AMD were paying, so there was no real chance of the project being done other than how it was. > Frank on the other hand has very few optimizations -- it is about lines of > code > that carry meaning. It is a goal of the project to "separate optimizations > from > the meanings" so it would still run with the optimizations turned off but > slower. I liked so much that I have adopted it as a goal for my PhD project. I will attempt a different path than VPRI (partial evaluation of nested interpreters instead of a chain of compilers) so we can better explore the territory. > We have done very little of this so far, and very few optimizations. We can > give > live dynamic demos in part because Dan Amelang's Nile graphics system turned > out to be more efficient than we thought with very few optimizations. Here is were the binary blob thing in the Raspberry Pi would be a problem. A Nile backend for the board's GPU can't be written, and the CPU can't compare to the PCs you use in your demos. > I think it could be an valuable project for interested parties to see about > how to > organize the separate "optimization spaces" that use the meanings as > references. I didn't get the part about "meanings as references". Reuben Thomas asked: > I'm baffled as to how having separate storage for different components > helps. Could you explain? I'd've thought it would be easier to use if > they were all available at the same time. Hans-Martin Mosner replied: > The reason I hope that separate media encourages experimentation is that > you're > much less likely to brick your device, either by your own actions or by some > innocently-looking upgrade. I know that on my Ubuntu desktop, I've been > bitten by > incompatible OS upgrades several times, which meant that I had to revisit > software > that was working perfectly well before such an upgrade just to make it > runnable again. That is a very good point, but the reason why I have tried to design my computers with 100% removable media is so they can be shared in a classroom. Even at $35 a class might not have one per student. If you have 10 machines and 30 students, each with their own SD card, it works better than if you have permanent stuff inside each computer. Though today's users have learned to cope with hard disks and installing software, the old floppy-only machines were actually easier for them. This worked pretty well for the Alto: http://www.computerhistory.org/revolution/input-output/14/347/1858 -- Jecel _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
