C. Scott Ananian wrote on Sat, 21 May 2011 19:22:01 -0400 > I'm familiar with the processors designed for specific high-level > languages. There was another generation of them built for Java > (microblaze, picoblaze, etc) and some of those are even still > commercially significant (they run Java subsets on smart cards).
You were probably thinking of PicoJava, the very first processor for which Sun made the sources available (Microblaze and Picoblaze are 32 and 8 bit processors from Xilinx). I would recommend that anyone interested in this take a look at the Java Oriented Processor: http://www.jopdesign.com/ I keep a list of Smalltalk computers (some with commercial processors, others with language specific CPUs): http://www.merlintec.com:8080/hardware/26 > I'm not terribly interested in those processors. Fair enough, but not only am I extremely interested in them, I also feel they can be a suitable "learning object". I imagine many here are a bit tired of hearing about my SiliconSqueak project, but it is important to point out that it is organized as a sequence of layers: 1) Tiled entry level language: Etoys, Scratch but could also be Turtlescript 2) System language: Smalltalk, but could also be Python or Lua 3) Bytecodes 4) "Microcode", but could also be assembly for ARM or Chuck Thacker's TinyComputer designs 5) Cache level (this is a unique SiliconSqueak thing) 6) logic circuits I think it is reasonable to introduce all children to 1, but for any given level I expect only a tiny fraction to move on to the next level. This is just natural so out of millions of people only two or three might be interested in level 5. Even so, I am willing make as much effort as I can to create a nice learning experience for those three. Level 6 breaks the pattern since it can used for many different interesting projects beyond SiliconSqueak, so many people might be interested in it. I would like to point out the workshops Etienne Delacroix created in Brazil and Uruguay in the past decade as a good example of what can be achieved in this regard. > More in tune with the "turles all the way down" agenda is the work > done on compiling high level languages to hardware. It's not that the > hardware chipset runs turtlescript (that's not really giving you any > additional insight into the operation of the hardware), but that the > hardware is *described* in turtlescript. I've made some modest > contributions to this in the distant past > (http://flex.cscott.net/SiliconC/paper.pdf). Nice dream, and I say this as someone who is part of a group of research groups dedicated to making the dream of programming hardware in C come true. The paper doesn't have a data, but from the references I would guess 1996 or 1997. So it doesn't mention System C, Handel-C (killed off, unfortunately) or BlueSpec. Personally, I would select something like Matlab (Octave) as a source language for hardware instead of C. By a strange coincidence, a top researcher in this field was trying to get me intereted on working on the problem of compiling recursive functions to hardware. My own PhD project, "Adaptive Compilation for a Reconfigurable, Parallel, Object-Oriented Architecture", is not entirely unrelated to this. > That said, there is *zero* chance that this work will result in > hardware suitable for the kids we care about. So let's stop talking > about it. This is exactly what I hope will be the result. But I agree this is not the right place to talk about it. > > I once used a tile-based UI in a commercial database program. It was > > horrible once we got past the toy examples. [...] > > Of course. I would say that perhaps 40 or 50 blocks is a reasonable limit. > > After that, you should be writing subroutines to go in Python blocks, and > > not very long after transition to pure Python. > > Let's find out. > > I've written almost 4,000 lines of code in my "tile based language" so > far. So far I've been typing it. I hope to leave the keyboard behind > soon. And then we'll see whether I agree with you or not. One problem is that graphical representations are very rich, but not very dense. So factoring stuff better can help a lot (see any code by Chuck Moore). Another solution is to go beyond 2 dimensions - a program is really something that evolves in time and you could make its representation reflect that. I hope to use animation to unify: 1) using the computer with pop up menus and dialog boxes, 2) writing scripts, 3) debugging. Textual representations are really bad at references, unfortunately, beyond a small set of literals, the arguments and some globals. In Etoys I can use any object's halo to ask for a tile representing it and then use this tile in some expression. In Self I could set the value of a local variable by dragging an arrow to point to anything I wanted. My goal is to bring levels 1 and 2 (of my list above) together so the transition won't even be noticed. -- Jecel _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
