Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!think!ames!aurora!labrea!decwrl!decvax!yale!mfci!root From: root@mfci.UUCP Newsgroups: comp.arch Subject: Re: Intel 432's evolves into a RISC??? Message-ID: <225@m2.mfci.UUCP> Date: 23 Jan 88 16:52:35 GMT References: <243@spar.SPAR.SLB.COM> <2707@omepd> <1071@cpocd2.UUCP> Reply-To: mfci!colwell@uunet.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford, CT. 06405 Lines: 58 Posted: Sat Jan 23 11:52:35 1988 In article <1071@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >In article <2707@omepd> mcg@omepd.UUCP (Steven McGeady) writes: >>Moreover, the comparisons, if made by object-oriented, fault-tolerant, >>CISC computer zealots, would refer to the advanced, pioneering, >>glimpse-of-the-future 432 processor, while comparisons made by the RISC, >>anti-Intel, and architectural purity zealots would refer to the abysmally >>slow and commercially unsuccessful 432. > >I'm an object oriented, fault tolerant, RISC zealot who works for Intel. >Where does that leave me? 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. > >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. > >-- > Howard A. Landman > {oliveb,hplabs}!intelca!mipos3!cpocd2!howard > howard%cpocd2.intel.com@RELAY.CS.NET > One hand clapping sounds a lot like two hands clapping, only quieter. Some opinions of my own: 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) 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. 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. 3) in spite of all of the above, the datapaths of the 432, including all of the runtime address checking and pointer caches, was very simple, perhaps of the same order as the RISC-II, and definitely simpler than the AMD 29000. 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... Bob Colwell Multiflow Computer ...yale!mfci!colwell@uunet.uucp 203-488-6090