Hi Jecel
I think both these sections were reactions to some of the current hardware, and
hardware problems of the time.
I remember the second one better than the first. In those days cutting dies out
of the wafters often damaged them, and the general yield was not great even
before cutting the die out. This idea was to lay down regions of memory on the
wafer, run bus metalization over them, test them, and zap a few bits if they
didn't work. The key here was that the working ones would each have a register
that had its "name" (actually its base address and range) and all could look at
the bus to see if their address came up. If it did, it would seize the bus and
do what ever. So this was a kind of distributed small pages and MMUs scheme.
And the yield would be much higher because the wafers remained intact. I don't
think any of these tradeoffs obtain today, though one could imagine other kinds
of schemes for distributed memory and memory management that would be more
sensible than current schemes.
The first one I really don't remember. But it probably was partially the result
of the head per track small disk that the FLEX machine used -- and probably was
influenced by Paul Rovner's scheme at Lincoln Labs for doing Jerry Feldman's
software "associative triples memory".
I think this was not about Denis Seror's later and really interesting thesis
(under Barton) to make a "lambda calculus machine" -- really a "combinator
machine" (to replace variables by paths) and to have the computation on the
disk and just pull in and reduce as possible as the disk zoomed by. All was
done in parallel and eventually all would be reduced. Denis came up with a nice
little language that had a bit of an APL feeling for humans to program this
system in. He (and his wife) wound up making an animated movie to show people
who didn't know about lambda expressions and combinators (which was pretty much
everyone in CS in those days) what they were and how they reduced.
There's no question that Bob Taylor was the prime key for PARC (and he also had
paid for most of our PhDs in the 60s when he was an ARPA funder).
Cheers,
Alan
>________________________________
>From: Jecel Assumpcao Jr. <[email protected]>
>To: Alan Kay <[email protected]>
>Cc: Fundamentals of New Computing <[email protected]>
>Sent: Thursday, September 1, 2011 3:17 PM
>Subject: a little more FLEXibility (was: [fonc] Re: Ceres and Oberon)
>
>Alan,
>
>> The Flex Machine was "the omelet you have to throw away to clean the pan",
>> so I haven't put any effort into saving that history.
>
>Fair enough! Having the table of contents but not the text made me think
>that perhaps the section B.6.b.ii The Disk as a Serial "Associative
>Memory" and B.6.c. An Associativeley Mapped LSI Memory might be
>interesting in light of Ian's latest paper. Or the first part might be
>more related to OOZE instead.
>
>> But there were "4 or 5" pretty good things and "4 or 5" really bad things
>> that
>> helped the Alto-Smalltalk effort a few years later.
>
>Was being able to input drawings one of the good things? There was one
>Lisp GUI that put a lot of effort into allowing you to input objects
>instead of just text. It did that by outputting text but keeping track
>of where it came from. So if you pointed to the text generated by
>listing the contents of a disk directory while there was some program
>waiting for input, that program would read the actual entry object.
>
>It is frustrating for me that while the Squeak VM could easily handle an
>expression like
>
>myView add: <yellowEllipseMorph> copy.
>
>I have no way of typing that. I can't use any object as a literal nor as
>input. In Etoys I can get close enough by getting a tile representing
>the yellowEllpiseMorph from its halo and use that in expressions. In
>Self I could add a constant slot with some easy to type value, like 0,
>and then drag the arrow from that slot to point to the object I really
>wanted. It was a bit indirect but it worked and I used this a lot. The
>nice thing about having something like this is that you never need
>global variable again.
>
>> I'd say that the huge factors after having tried to do one of these were two
>> geniuses: Chuck Thacker (who was an infinitely better hardware designer and
>> builder than I was), and Dan Ingalls (who was infinitely better at most
>> phases
>> of software design and implementation than I was).
>
>True. You were lucky to have them, though perhaps we might say Bob
>Taylor had built that luck into PARC.
>
>-- Jecel
>
>
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
