On Tuesday 18 March 2003 16:27, Alan Kay wrote:
> The Xerox PARC various architectures were all emulation architectures
> and employed microcoding for the lowest levels of VM for the various
> languages that were run on them. These typically ran at about 5 times
> the speed of the main memory and isolated the fetches of the
> microcode from the main memory fetches.

But these were TTL machines. MOS processors were actually much slower 
then memory and when they caught up in the mid 1980s we got the RISC 
era. Only close to the mid 1990s was the industry in the same situation 
as PARC had been.

> This allowed all important
> inner loops to run at the speed they would have run if they were hard
> coded into logic. In addition, there were various hooks in different
> machines to deal with bytecode dispatch, "zero overhead multitasking"
> at the lowest level of the machine (e.g. the Alto had 16 program
> counters and parallel lookaside logic to decide which one would
> deliver the next instruction on the next cycle), etc.  It had a
> display list even though it was a bitmap machine. This allowed for
> zero overhead double buffering and other ways to manage the display.
> The Notetaker was a multiple processor machine with a very nice
> arbitration bus that allowed display and IO processors to dovetail
> with the language processor, etc.

The low end home computers (TI99/4, Atari, Commodore 64...) probably 
came the closest to this with their sound and graphics "processors". 
More serious machines were simpler.

> The main idea here is that in the end the programmers want to program
> in a very high level language, and the machine should be as
> configurable as possible towards helping the best conceived
> environment run as fast as possible. A secondary idea is that it is
> hard to design when you have your optimization hat on, and thus, if
> you want to make progress with interactive language design, you want
> to be able to start using your latest and greatest ideas with as
> little special optimization as possible.
>
> These are *not* goals that Intel and Motorola understood, anymore
> than they understood anything important about SW in general.

These were only very enhanced fuel pump/microwave oven controllers, 
after all. Though to be fair, Intel did have the iAPX432 (even if it 
has been purged from their official history).

> The
> current caching schemes are rudimentary to say the least. The more
> interesting architectures today are the graphics accellerators --
> they don't do anything particularly new, but they at least have some
> notion of what they are supposed to do (and also what they don't have
> to do when Moore's Law makes it easy to have multiple processors).

They are interesting, but they hardwired SGI's graphics pipeline killing 
the possibility of experimenting with alternatives. Attempts like 
Microsoft's Talisman  
(http://research.microsoft.com/MSRSIGGRAPH/96/Talisman/) or Stanford's 
Imagine (http://cva.stanford.edu/imagine/index.html) were as easily 
squashed as a Forth processor in a x86 world :-(

I have been learning a lot trying to fit Smalltalk into 15 thousand 
gates (http://www.merlintec.com:8080/Hardware/Oliver) and feel that my 
larger projects will be far better because of this.

-- Jecel