[self-interest] Re: Klein, ARM and Self Hardware

[Jecel Assumpcao Jr.]

Jan-Paul Bultmann wrote:
> Yeah, running on the ipad would be rad, but is impossible.
> That's why I like the touchbook, its open source hardware.
> On Dec 15, 2010, at 11:10 PM, Michael Latta wrote:
> > Also note that any talk about porting to iOS will hit a security wall.
> > They do not allow dynamically generated code for security reasons.
> > They use the noexecute bit on all data pages and only static signed
> > code gets into an executable page. If you want to run on iOS you
> > need the option to generate static code that can be signed.

You can't have any kind of programming language in the app store, so I
don't think there would be a way to distribute Self even if it were just
a simple interpreter. See Squeak, Etoys and Scratch and their adventures
on the iPad.

I think Jan's suggestion of the Touchbook or similar is the way to go.

> > [Klain can run on a Self VM for a processor it doesn't support]
> Yea but the DebugServer xcodeproject is made for PPC and needs
> a bit of modification first, I thought that it was mainly developed on
> an intel mac first :).

Right - I had forgotten the DebugServer.

> While I love the idea of custom self hardware, and like the design
> of the RISC42, it might be more practical for the start to use
> something that is easier to set up (I don't think many users will be
> able to do their FPGA :) while  everybody with the spare buck for a
> beagleboard could start right off).

I agree 100%. Those were projects I was interested in, not that I would
recommend other people work on. I see them as interesting from a
historical perspective. Since my projects using conventional processors
are much better documented, here is a brief outline of my Self
processors:

1990-1991: various dataflow style designs that were dropped in favor of
a modified Sparc when the data from the Self project became available.
This chip was easy to configure as an embedded controller, a node for a
parallel machine or as a low cost children's computer.

1991: after the above project was cancelled as "not academic enough" by
my boss, I came up with a radical concept that some 8 years later
evolved into RNA (http://www.merlintec.com:8080/hardware/19). This was
immediately rejected by my boss.

mid 1990s: a vague idea called "Snow White and the Dwarves" would have a
large processor implementing adaptive compilation in hardware with a
bunch of simple processors only capable of running fully optimized code.
The idea was that many passes of only local optimizations can get you
the same effect as more global optimizations.

1998-2001: Tachyon was a VLIW MOVE processor (4 moves of 16 bits each
per clock cycle, plus 6 more moves in special loop processors) with
768KB of high speed external memory as an instruction and data cache.
The main memory would only hold bytecodes, so the compiler had the job
of reloading the instruction cache.

2001-2007: Plurion had several simple stack processor, each with its own
cache (the internal memory of FPGAs became much larger starting with the
Virtex II). This didn't need the really fancy compilation techniques
that Tachyon wouldn't work without.

2007-2008: RISC42 was optimized as the target of an adaptive compiler,
while Plurion was more like a fast interpreter.

> When doing custom hardware I would maybee even do something
> radically different. Say 1000 primitive Cores with moderate cache
> for each one and no ram.

This is on our roadmap for SiliconSqueak - a wafer scale device using an
older 250nm technology to fit 16 thousand processors, each with a large
local cache, into a $500 supercomputer.

> When self was then retrofittet with some bits of the actor model,

Have you seen my tinySelf 1 experiments?

http://www.merlintec.com/lsi/tiny.html#rel1

Or David Ungar's current work?

http://www.stefan-marr.de/tag/roarvm/

> we could simply load one object per core and let them communicate
> via message passing :D so skipping ram entirely would bring a
> performance boost that would make the "slow" message passing worth
> it. But thats a story for another day (and my personal dream cpu so...;)).

Once you have the objects living in their own processors and exchanging
actual messages over some communications network, you could replace some
of these objects with dedicated hardware blocks and the rest of the
system would not notice (except for some increase in performance).
Reinaldo Silveira took the first step in this direction with his PhD
thesis on using Self as a hardware description language (unfortunately
the text is in Portuguese, but even just the pictures are interesting):

http://www.merlintec.com/download/selfHDL.pdf

He didn't continue this work, which would involve generating the
hardware instead of just simulating it and then converting "normal" Self
objects into SelfHDL.

> I love the merlin :D I really think it could massively reform education.
> But I think we could be better off using of the shelf parts (and the
> touchbook looks a bit like the merlin :)), so we can focus on the things
> that are "easy" and that users will feel an impact from.

Sure, but the best way to impact people is to run on the machines they
already have (some kind of PC, most likely). On the other hand, if Klein
runs on the bare hardware then it will be too complicated for people to
install it beside their current operating system. One option is to use a
virtual machine (in the sense of Qemu or VirtualBox) and another is to
run on hardware cheap enough that people won't mind too much buying an
extra machine. I would agree that the Touchbook is an example of this.

-- Jecel