malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (01/12/88)
Intel RISC Due in Spring; Details at ISSCC From EE Times (January 11, 1988, p 2). Hillsboro, OR - Intel Corp. will spring a single-chip embedded microcontroller that will be its first design to employ RISC techniques this spring. The device is part of the 80900 family under development as part of the Gemini project here. .... ..... The microcontroller design is based on the architecture of a three- chip set that includes the rumored P-7 microprocessor. Gemini is a revival of the concepts of Intel's pioneering effort in redundant fault tolerant processing -- the iAPX 432 chip set,.... Let me get this right.....the absolute biggest of the CISC's (the 432) is evolving into a RISC? Maybe EE Times left the :-) off the article. Malcolm
mcg@omepd (Steven McGeady) (01/15/88)
-------- In article <243@spar.SPAR> malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) writes: > > Intel RISC Due in Spring; Details at ISSCC > From EE Times (January 11, 1988, p 2). > >Let me get this right.....the absolute biggest of the CISC's (the 432) is >evolving into a RISC? Maybe EE Times left the :-) off the article. > Considering that the last major piece of silicon that Intel's Oregon Microcomputer Engineering group released was the 432, it seems likely that anything the group released, be it a processor or a popcorn maker, would be compared to the 432. This is especially true in the case of journalism (and I use the term loosely) in the absence of facts, such as the mentioned EE Times article. 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 suggest that you wait for the ISSCC paper and make up your mind at that time. S. McGeady Popcorn Maker Division Intel Corp.
howard@cpocd2.UUCP (Howard A. Landman) (01/20/88)
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.
bcase@apple.UUCP (Brian Case) (01/23/88)
In article <1071@cpocd2.UUCP> howard@cpocd2.UUCP (Howard A. Landman) writes: >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 Waaait a minute. I'm sure Howard knows what he is talking about and that his point is valid, but it is somewhat badly stated (and I am compelled to clear up the mistatement). There are other uses for chip area than data path, register file, and cache. There are bus controllers and special function units to name two. A very complex bus controller might be necessary, and it might take up significiant area, but its presence doesn't make a CISC. As technology improves, the test as Howard states it will be less and less accurate (I think). BTW, I have recently heard some people from Australia and England pronounce CISC as "kisk." Anyone know if this is the way it really "should" be pronounced. Respond by mail please....
root@mfci.UUCP (01/23/88)
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 <Standard disclaimer: Multiflow doesn't care what I think about the 432>
howard@cpocd2.UUCP (Howard A. Landman) (01/29/88)
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"