Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hoptoad.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch
Subject: Re: IBM RT PC, 801, RISC horserace, etc.
Message-ID: <449@hoptoad.uucp>
Date: Tue, 28-Jan-86 16:59:04 EST
Article-I.D.: hoptoad.449
Posted: Tue Jan 28 16:59:04 1986
Date-Received: Thu, 30-Jan-86 06:16:26 EST
References: <1328@sdcsvax.UUCP> <5100001@ccvaxa>
Organization: Nebula Consultants in San Francisco
Lines: 46

In article <5100001@ccvaxa>, aglew@ccvaxa.UUCP writes:
> Why did IBM not release news about the 801 until just about now?
> Paranoid answer: because the 801 RISC approach was valid when VLSI
> was young (just how long has Patterson's RISC group been going on)
> but is no longer applicable...

It's not clear whether RISC is a win or not -- we'll only see after
they've been in the marketplace for a few years.  It *is* an
interesting idea; the catch is software.  Can a complicated compiler
generate correct code that is faster than what a very very smart
microcode author could write and put into a non-RISC machine?  Indeed,
the microcode has to do more work (decode instructions, etc) but the
human is smarter than the compiler.  It's a horse race.

>                                                      Microcode
> was a lump that lay across the chip boundary - RISC placed this lump
> outside because it couldn't all be fitted inside - maybe IBM can now
> squeeze it all onto the chip?)

RISC moves that boundary from "between the microcode and the
ALU/sequencer" to "between the main memory and the ALU/sequencer".
This is another factor that tends to make RISC lose, since it's always
possible to build a small wide (microcode) memory faster than you can
build a large main memory.  But there are complications you can add to
the large main memory such that *most* of what you reference ends up in
a small fast memory -- cacheing.  The "win" of less decoding
overhead has to outweigh the "lose" of more main memory activity, (plus
the cost of the more complex main memory) or RISC is not competitive.

The technical info I've seen on the IBM RT PC so far doesn't mention
cacheing (except page map cacheing) and the compiler technology sounds,
from John Levine's message, pretty mundane.  Also, the chips are old
technology (NMOS with 2 power supplies and 2.4 watts of heat generated
per chip -- each one requires a heat sink) compared to today's micros
by commercial micro companies (Intel, Motorola).

This, plus the deadbeat graphics and network hardware for the RT PC,
makes it sound like they haven't shot their wad yet (in the usual IBM
fashion) but are giving us a two year old product and seeing how many
people will spend money on it before giving us this year's product.
Don't ever forget that IBM's in business to make money, not to give you
leading edge products.
-- 
# I resisted cluttering my mail with signatures for years, but the mail relay
# situation has gotten to where people can't reach me without it.  Dammit!
# John Gilmore  {sun,ptsfa,lll-crg,nsc}!hoptoad!gnu    jgilmore@lll-crg.arpa