Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!ucsd!ucsdhub!hp-sdd!hplabs!hp-pcd!uoregon!omepd!mipos3!td2cad!cpocd2!howard
From: howard@cpocd2.UUCP (Howard A. Landman)
Newsgroups: comp.arch
Subject: Re: Intel 432's evolves into a RISC???
Message-ID: <1094@cpocd2.UUCP>
Date: 28 Jan 88 21:54:09 GMT
References: <243@spar.SPAR.SLB.COM> <2707@omepd> <1071@cpocd2.UUCP> <225@m2.mfci.UUCP>
Reply-To: howard@cpocd2.UUCP (Howard A. Landman)
Organization: Intel Corp. ASIC Systems Organization, Chandler AZ
Lines: 63

In article <1071@cpocd2.UUCP> I write:
>I personally remember the "abysmally slow" 432
>better than the other ones you mentioned.  As far as I'm concerned, that
>makes the 432 a bad architecture for object-oriented languages.

In article <225@m2.mfci.UUCP> mfci!colwell@uunet.UUCP (Robert Colwell) writes:
<1) The 432 was indeed abysmally slow;  that in now way meant its
<architecture was bad for object-oriented languages.  It meant that
<its implementation wasn't good enough;  there's a very big difference.
<(a paper will appear this year in ACM TOCS on this -- a recap of my
<phd thesis)

You're right, of course, that one bad implementation doesn't "prove" that
an architecture is bad.  But it's all we have to go on.  If you are implying
that there was a good way to implement the 432 architecture, I'd be interested
in reading your comments.

I write:
>If anyone sees a photo of the chip, here's an easy way to tell RISC from CISC:
>Identify the datapath and RAM (including register file and cache).  If they
>add up to less than half the chip area, it's a CISC.  That's because the rest
>is probably all control, and any chip that's more than half control does not
>have a simple architecture.

Robert writes:
<2) there wasn't one chip, but three:  the execution unit, the instr
<decode unit, and a chip to do I/O.  According to your definition, the
<execution unit might well qualify as a RISC.  But I don't agree with
<that definition.

I was talking about the new chip, not the 432.  I never said the 432
was one chip.  But if we count the instruction decode chip as 100%
control, the execution chip as about 50% control, and the I/O chip as
some non-zero percentage control, they average out well over 50%.  The
execution chip, alone, can't be considered a RISC because it isn't a
computer, just a piece of one.

<To me, we're long past the point where we can count registers, instrs,
<addressing modes, or chip area ratios and say RISC or CISC.  What made
<the 432 a CISC, in my opinion, was its insistence on doing everything
<at runtime, and in hardware.  That led to a large instruction set which
<could directly express high level language constructs, which in turn
<reuqired a large microcoded execution engine, and so on.

The quick look was not meant to be a scientific definition of RISCness versus
CISCness; it's just something I've observed in looking at dozens of chip
photos.  As a quick rule of thumb, it's likely to be misleading in some cases,
but I've never seen one yet where it was wrong.  Although the term RISC itself
is almost meaningless these days, it's been abused so often.

Robert writes:
>And I suspect that if you explicitly
>stated your premise about the deleterious effects of architectural 
>complexity, I'd disagree with it, but that's a another long story...

Yes, it is, and better people than I have written about it.  Try Patterson's
(Hi Dave!) and Katevenis' (Hi Manolis!) papers.

-- 
	Howard A. Landman
	{oliveb,hplabs}!intelca!mipos3!cpocd2!howard
	howard%cpocd2.intel.com@RELAY.CS.NET
	"We can't go on together, with suspicious minds"