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

[Jan-Paul Bultmann]

On Dec 16, 2010, at 4:43 AM, Jecel Assumpcao Jr. wrote:

> 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.
> 
Cool thing :D I think massive core parallelism suits a prototype based language better, since you can load an entire object into the core and dont worry about shard methods, it's all there, it might be duplicated across the system, but thats a small price to pay, since memory is cheap and latency is expensive. (kevo would fit this even better)
> > 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
> 
Yea I really like it. It seems to be based on the actor model right? It's not explicitly stated, but lazy locks( aka futures) and asynchronous message sends are pretty much all that is to a-m :D

> 
> Or David Ungar's current work?
> 
> http://www.stefan-marr.de/tag/roarvm/
> 
Not yet, looks interesting.


> 
> > 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).
> 
Yea once you have enough cores you can specialize, by letting some do floating point only and some do integer only.
Hardwiring entire objects seems reasonable too :)

> 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.
> 
While I like the Idea of everything done in Self, I think hardware is not practical.
We can have such a open security model, like message passing, and nonexistent typing, because we can fix the system when something goes wrong. Simply use the rad debugger and off you go.

When designing hardware you want to do it right the first place. Therefore I think hardware design should be made with a language like Haskell, where you can proof the crap out of the system :D

> 
> > 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20101216/ff3900f9/attachment.html>