MISC

[Alaric B. Williams]

On 29 Apr 97 at 2:27, lispos@math.gatech.edu wrote:

> > The problem, as always, is memory bandwidth.
>
> Exactly. 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,
since more instructions are needed to get anything done, and there
is still the demand for vast bitmaps and other multimedia gimmicks.

What gives? If you want to do graphics with a 1024x768 screen,
and lots of off-screen bitmaps, you can either use a MISC CPU with
SRAM fast enough to keep it fed - or a CISC CPU with slow RAM, but
it packs more punch per byte. Either way, you still need the 
megs of video and buffer RAM; the CISC approach will be cheaper,
since the DRAMs are cheaper, even though the MISC will be blazingly
fast...

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!

> > A MISC-like system, in fact veritably VLIW,
>
> Uh??? Current MISC processors have 5bit/instruction,

Yes, but you need a lot of them to do stuff. VLIW just
packs them together into convenient chunks :-)

> as compared to 128bit/instruction on a VLIW processor.

> Of course, the tradeoffs of MISC vs VLIW are completely different;
> but the whole idea of MISC is to move intelligence into software,
> whereas VLIW failed to move intelligence into hardware,

Hang on a sec. VLIW moves intelligence /out/ of hardware by letting
the compiler do the microscheduling stuff usually done by the microcode,
right?

> 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...
I mean, if you want a huge bitmap (common), you're going to
need a meg or two for it. Whatever the CPU attached.
Spreading that into lots of little fast SRAMs will be costly
compared to a big DRAM; the fast SRAMs will be fast, especially
since each line of the image has it's own CPU for manipulating it,
say, but at a vast COST...

> If a CL core would have to fit every host,
> there would be no space for user memory!
> [Reminds me of those useless clusters of intel i860
> with half of each CPU's 16MB core being taken by OSF/1].

Yum!

> > ARGON, BTW, is a /standard/ like POSIX rather than an actual bit

> Well, "will be" ;-> -- much like Tunes, actually )-8

Alas, alas, but we are young - we haven't had time to implement
anything yet :-)

> 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... so let's just guide 'em in the right direction when choosing
existing languages and in VM design for now :-)


ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html