Path: utzoo!mnetor!uunet!yale!mfci!root
From: root@mfci.UUCP (SuperUser)
Newsgroups: comp.arch
Subject: Re: Survey of architectures was (Re
Message-ID: <367@m3.mfci.UUCP>
Date: 26 Apr 88 13:00:49 GMT
References: <95544@<1988Apr22> <76700022@uiucdcsp>
Reply-To: colwell@m3.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 44

In article <76700022@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes:
>>>Intel 432: The ultimate CISC == Horrible failure.
>>
>>(as I climb back on one of my soapboxes...)
>>You must mean a failure in the commercial marketplace.  So what?  Are
>>you attributing that failure to its CISC nature?  If so, I contend
>>you are wrong, and if not, then what's your point?
>>
>>Bob Colwell            mfci!colwell@uunet.uucp
>
>It is a fact of history that the chip was a commercial failure.  If,
>as you assert, its architecture was not a failure, then by all means
>name one architecture that was influenced (in a POSITIVE way) by the
>Intel 432.
>
>Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois

Hmmm.  There's no easy answer to that one.  Unfortunately, the 432
was such a *miserable* commercial failure that nobody (well, almost
nobody) tried to look behind the large elapsed execution time numbers
to see why they were so large.  Perhaps because the RISC bandwagon
was just getting rolling then, the 432 became a CISC scapegoat, and
everybody assumed that it was slow because a) it had 7 levels of
indirection in its addressing, b) it had loads of complex
instructions, c) it was object-oriented, d) all of the above.  I
tried to show in my thesis that none of these was the real problem.

It isn't fair to require that the 432 have had an influence on other
machines for several reasons.  One is that nobody paid any attention
to it (and I grant you that you can cry "chicken-and-egg" here, but
before you do, please read the short version of my 432 work to appear
in June's ACM TOCS).  And the other is that maybe it addressed issues
that were just too far in the future, and still are.  The basic goal
of the machine was to trade off basic performance for other things
that were felt to be more important at the time, like programmer
productivity (and please hold the flames about how that can't be
achieved if the machine is dog-slow; that isn't the point) .  Perhaps
the day will come when we return to that viewpoint.  But it's not
here now, so it's unreasonable to require any obvious influences.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090