[IAEP] Turtles All The Way Down

[Jecel Assumpcao Jr.]

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