MISC

[Fare Rideau]

FOLLOWUP-TO: misc@pisa.rockefeller.edu

Subscribe on misc-request, I guess. Related URLs:
http://pisa.rockefeller.edu:8080/MISC/
http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/OSes.html#MISC

Let's move talk about the MISC architecture
out of the LispOS and LispVM mailing lists.
It suffices to us to know that such is an architecture
that a novel OS ought to *eventually* support.
Our current plans are directed to
currently standard cheaply available architectures,
the same that Linux and suches run on...

>>>: Alaric
>>: Fare
>: Alaric

> On 29 Apr 97 at 2:27, lispos@math.gatech.edu wrote:
Alaric, you quoting software sucks!

>> The largest the memory, the slowest;
>> so that when technology improves, the speed of CPUs
>> grows much faster than the speed of memory.
>> MISC processors are so small they'd come as an extension to RAM chips,
>> so each has a small amount of extra fast RAM,
>> instead of huge amounts of slow RAM, keeping RAM and CPU speed adapted
>> to each other.
>
> Hang on - so the system overally has less RAM... yet it needs more,

You seem to not understand that the amount of overall RAM is going
to be the exactly same as with CISC, growing at the same pace.
So the system overall has just as much RAM, but many more CPUs.
Each CPU indeed only has a limited amount of RAM (say, less than 1MW).
   What's changing is that instead of having a one bloated slow processor
with bigger instructions, we'll have a cluster of tiny minimal processors
with simpler instructions.
   So that, for a computer handling a few GB or RAM,
instead of having a one 10M transistor Alpha at 500MHz
you will have a thousand 10000 transistor MuP32 at 2GHz.
Even if each MuP32 is inherently, say, 40 times less powerful than an Alpha,
it will run 4 times more quickly, and we'll have 1000 times more of them,
so for as many bucks, we'll have 100 times more computing power.
   See what I mean?
   Moreover, because it's so small, the MISC computer can be
integrated in the RAM chip, so it doesn't have to pay the speed overhead
(and hardware cost) of an inter-chip bus.
   Of course, for *intrinsically sequential* problems
(and there exist some of them), you might prefer the Alpha.
However, most problems in everyday life would happier with
the cluster of processors. The most heavy power crunching software
out there is mostly simulation of physical phenomenon,
and we all know well how nature is intrinsically parallel.

Again, C and C-based OSes can't and will never be able to
handle such architectures properly. Lisp and a LispOS could,
if only we keep the code high-level and pure enough
so it can be factored and parallelized...

> Dave Hudson's joining the list. He explained all this to me when I
> designed my own super-fast CPU... Dave, where are you?!?! You explain
> it, you're a hardware engineer!
   Yeah, Dave is a MISC expert. Dave, please correct any inexactness
that might have slipped in my explanations...

> Hang on a sec. VLIW moves intelligence /out/ of hardware by letting
> the compiler do the microscheduling stuff usually done by the microcode,
> right?
Nope. VLIW puts lots of bloat in hardware, including all the bloat
related to decoding instructions and handling memory.
VLIW *might* be a good idea in a few intrinsically sequential problems.
It just isn't worth its bang/buck as a generic computer architecture.

>> A reason I have against a CL-based OS, to me,
>> is that it wouldn't fit the model of having clusters of cheapo MISC chips,
>> each with a limited amount (a few hundreds KW) of on-chip RAM.
>
> The cost of all these little bits of RAM soon add up, though...
>
1GB of DRAM and 1MB or SRAM (for cache) cost the same,
whether it's plugged to a unique CISC/RISC, or have 1000 on-chip MISC.
And again, on-chip MISC can access the RAM faster,
and removes the cost of a RAM bus on the motherboard.

>> NB: I've tried to cut the Tunes&Argon hype, too...
>
> Ok. Anyway, a little point I'll make... our totally-next-generation
> language talk isn't /incredibly/ useful to the LispOS people,
> though, since they wanna get something built together cheaply with
> easily available technologies, a la Erik Naggum's "worse is better"
> paper...
The paper is Dick Gabriel's. Erik Naggum just pointed at it.

> so let's just guide 'em in the right direction when choosing
> existing languages and in VM design for now :-)
Being a little older than you, I don't pretend anymore to guide anyone.
I just expose and propose ideas to find a way out of the current mess.

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"