rcd@ico.ISC.COM (Dick Dunn) (10/11/89)
This week's EE Times features a front-page article about IBM's forthcoming
line of RISC machines based on the `America' processor, presented at ICCD.
The article mentions that the architecture has 184 instructions!
I don't know whether the EE Times folks got the count wrong (by somehow
double-counting for addressing modes or some such) or don't know what RISC
stands for...but it's clearly time for a new acronym:
ERISC - Extended Reduced Instruction Set Computer
as in "our machine has more fewer instructions than yours doesn't."
It would be interesting to know what the machine really looks like. Of
course, EE Times doesn't give any information about speed, and only one
vague guess about cost. The machine won't be out until some time next
year. But that doesn't stop them from proclaiming that IBM is at the head
of the pack! It's interesting that you can take the lead by talking about
what you're going to do...this wasn't even a product (pre)announcement.
Sigh...this sort of non-journalism doesn't do anyone--even IBM--any good.
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...No DOS. UNIX.firth@sei.cmu.edu (Robert Firth) (10/11/89)
In article <16190@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >This week's EE Times features a front-page article about IBM's forthcoming >line of RISC machines based on the `America' processor, presented at ICCD. >The article mentions that the architecture has 184 instructions! Well, that sounds like a lot of instructions. However, let's not forget that RISC is as much a philosophy as a statistic; it is still reasonable to claim a machine design has followed that philosophy even though it has 'lots' of instructions. >The machine won't be out until some time next year... >Sigh...this sort of non-journalism doesn't do anyone--even IBM--any good. Alas, I beg to differ. We have seen this strategy before from the dinosaurs, and it is very effective. What three-piece-suited executive is now going to order an R3000 or a SPARC, when in 12 months' time (or more like 18), Big Blue is going to come out with the Real Thing? This announcement will inhibit people from buying a new machine because it is less risky to wait and see.
phil@ingr.com (Phil Johnson) (10/13/89)
In article <4424@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >>The machine won't be out until some time next year... >>Sigh...this sort of non-journalism doesn't do anyone--even IBM--any good. > >Alas, I beg to differ. We have seen this strategy before from the >dinosaurs, and it is very effective. What three-piece-suited executive >is now going to order an R3000 or a SPARC, when in 12 months' time >(or more like 18), Big Blue is going to come out with the Real Thing? >This announcement will inhibit people from buying a new machine because >it is less risky to wait and see. This is very true. I remember, in the days of S100, SS50, etc, when IBM announced their intention to enter the personal computer market. This was announced nearly a year before the original PC was delivered, but during that period TIME STOOD STILL. Existing vendor slowed or stopped their development and buyers decided to wait. The world waited to see what technological wonders Big Blue would deliver. TA-DA enter the IBM-PC. After nearly a year of anticipation the world proclaimed the PC as a great and inovative approach. The only problem was that there were systems available that ran rings around the PC, but were left in the shadows of media hype as is so today. -- Philip E. Johnson UUCP: usenet!ingr!b3!sys_7a!phil MY words, VOICE: (205) 772-2497 MY opinion!
rcd@ico.ISC.COM (Dick Dunn) (10/14/89)
> ...rcd@ico.ISC.COM (dat's me) writes: [about the EE Times nearly content-free cover story on IBM's "America"] > >The machine won't be out until some time next year... > >Sigh...this sort of non-journalism doesn't do anyone--even IBM--any good. I had been thinking that YA announcement of this long-delayed machine would just make people more pessimistic that it ever will show. However... firth@sei.cmu.edu (Robert Firth) writes: > Alas, I beg to differ. We have seen this strategy before from the > dinosaurs, and it is very effective. What three-piece-suited executive > is now going to order an R3000 or a SPARC, when in 12 months' time > (or more like 18), Big Blue is going to come out with the Real Thing? I concede that Firth is right. I was reasoning about the situation...for example, that there's nothing remarkable about a someday-machine having better performance than a now-machine, or that the complete lack of either cost or performance info might be unnerving. But I was clearly being a Pollyanna; that's NOT how people think about machine acquisition in general, and especially when IBM is one of the potential players. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
philf@xymox.metaphor.com (Phil Fernandez) (10/15/89)
In article <4424@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >... >Alas, I beg to differ. We have seen this strategy before from the >dinosaurs, and it is very effective. What three-piece-suited executive >is now going to order an R3000 or a SPARC, when in 12 months' time >(or more like 18), Big Blue is going to come out with the Real Thing? >This announcement will inhibit people from buying a new machine because >it is less risky to wait and see. Wait a minute. Remember that many three-piece-suited executives making buying decisions know plenty about IBM's upcoming product and announcment, and are making wait-or-buy decisions based on those facts. For example, I was recently down to IBM's Advanced Workstation Division Austin center for a full briefing about the new IBM RISC line. I've seen and touched the boxes; I've heard concrete architecture, price and performance information. I definitely have enough information to make a wait/buy decision. (No comment on the decision; I'm under non-disclosure :) phil p.s. Oh, I only wore a two-piece suit... +-----------------------------+----------------------------------------------+ | Phil Fernandez | philf@metaphor.com | | | ...!{apple|decwrl}!metaphor!philf | | Metaphor Computer Systems |"Does the body rule the mind, or does the mind| | Mountain View, CA | rule the body? I dunno..." - Morrissey | +-----------------------------+----------------------------------------------+
rmiller@gmu90x.UUCP (Richard Miller) (10/17/89)
In article <16190@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >This week's EE Times features a front-page article about IBM's forthcoming >line of RISC machines based on the `America' processor, presented at ICCD. >The article mentions that the architecture has 184 instructions!... > ...ERISC - Extended Reduced Instruction Set Computer >as in "our machine has more fewer instructions than yours doesn't." > Believe it or not, the presenters DID redefine RISC! The now say that it stands for "Reduced Instruction Set Cycles"! So much for a convergence of the meaning of a too-nebulous term. What amazed me about this architecture more than the number of instructions was the anti-RISC approach to some of its elements. The most glaring ex- ample IMHO is the fact that its floating point processor implements register renaming in HARDWARE! There is nothing wrong with that in and of itself, but it is something that is almost trivially implemented in a compiler and therefore the RISC philosophers tell you to PUT it in the compiler. I believe that the only reason that the term RISC is associated with this architecture is for the marketing mileage that it gives them. Perhaps their efforts to redefine term are a token effort to assuage the confusion of those that can see through this somewhat blatant marketing ploy. >It would be interesting to know what the machine really looks like... A reasonable description of most of the architecture appears in the papers presented there -- the transactions are available. Rick Miller 11012 Howland Drive Reston, VA The opinions expressed here are my own. Please reply to rmiller@gmuvax2.gmu.edu
colwell@mfci.UUCP (Robert Colwell) (10/17/89)
In article <2393@gmu90x.UUCP> rmiller@gmu90x.UUCP (Richard Miller) writes: >In article <16190@vail.ICO.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: >>This week's EE Times features a front-page article about IBM's forthcoming >>line of RISC machines based on the `America' processor, presented at ICCD. >>The article mentions that the architecture has 184 instructions!... >... >I believe that the only reason that the term RISC is associated with this >architecture is for the marketing mileage that it gives them. Perhaps >their efforts to redefine term are a token effort to assuage the confusion >of those that can see through this somewhat blatant marketing ploy. It might help to consider a few more facts associated with this machine. The first is that the guy who started the whole RISC juggernaut was John Cocke, who was (and is) at IBM, and who was also involved (at least initially) with this America processor. The second is that the papers on the IBM 801 which enunciated the principles embodied therein don't emphasize the same things that the research efforts at Berkeley & Stanford did, so it's not that surprising that they don't religiously follow the tenets espoused by them. On the other hand, you could have a point. It just seems kinda weird to accuse the guys who started all this of mere marketing ploys. Besides, if the machine is as fast as they say, and if it doesn't qualify as a RISC (under some hypothetical reasonable definition of RISC), then it would seem some interesting (and undoubtedly amazingly inflammatory) conclusions might present themselves... Bob Colwell ..!uunet!mfci!colwell Multiflow Computer or colwell@multiflow.com 31 Business Park Dr. Branford, CT 06405 203-488-6090
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/19/89)
In article <1087@m3.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: | It might help to consider a few more facts associated with this machine. | The first is that the guy who started the whole RISC juggernaut was John | Cocke, who was (and is) at IBM, and who was also involved (at least initially) | with this America processor. The second is that the papers on the IBM 801 | which enunciated the principles embodied therein don't emphasize the same | things that the research efforts at Berkeley & Stanford did, so it's not | that surprising that they don't religiously follow the tenets espoused | by them. Very well put. | | On the other hand, you could have a point. It just seems kinda weird to | accuse the guys who started all this of mere marketing ploys. Besides, | if the machine is as fast as they say, and if it doesn't qualify as a RISC | (under some hypothetical reasonable definition of RISC), then it would | seem some interesting (and undoubtedly amazingly inflammatory) conclusions | might present themselves... From what I've read and heard, the reason for developing RISC was *not* as an end in itself, but for speed. By reducing the cycles per instruction more instructions per send would be executed. Only to do that the instruction set was made smaller. Enter RISC. I am a true believer in reducing the cycles per instruction, but I see no virtue in having fewer instructions for any reason other than speed. I am not offended by a chip with 1024 instructions, if it averages 1.1 cycles/op. Note that the 80486 and 68040 have increased throughput at a given clock speed. Intel has claimed (actually one of the officers said it in a speech) that the 586 would be <1 cycle/op average. I assume Motorola is not ignoring this. IMHO too many people are concentrating on the number of opcodes rather than the performance on real problems. Let's remember that RISC was originally a solution to a performance goal, not some "natural principle" which could be defended even if it had hurt performance. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
rmiller@gmu90x.UUCP (Richard Miller) (10/19/89)
With reference to the IBM America processor, in article <2393@gmu90x.UUCP> rmiller@gmu90x.UUCP I wrote: >>I believe that the only reason that the term RISC is associated with this >>architecture is for the marketing mileage that it gives them. Perhaps >>their efforts to redefine term are a token effort to assuage the confusion >>of those that can see through this somewhat blatant marketing ploy. In article <1087@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes: >It might help to consider a few more facts associated with this machine. >The first is that the guy who started the whole RISC juggernaut was John >Cocke, who was (and is) at IBM, and who was also involved (at least initially) >with this America processor. The second is that the papers on the IBM 801 >which enunciated the principles embodied therein don't emphasize the same >things that the research efforts at Berkeley & Stanford did, so it's not >that surprising that they don't religiously follow the tenets espoused >by them... It is interesting to note that Radin, in the earliest publication that I have on the 801 [The 801 Minicomputer, George Radin, IBM Journal of Research and Development, 27(3), May 1983] starts off his paper by stating that the distinguishing feature of the architecture is that it has a "straightforward, rather primitive machine cycle" and that "A similar general approach has been pursued by a group at the University of California." It is also interesting that the term RISC is never used in the article, even though the term had already been published (in an article referenced by Radin!). You do have a good point in that Radin emphasizes a clean pipeline cycle more than hardware minimization -- but it's hard to believe that the register renaming in the FPU is "free" by either metric. > >On the other hand, you could have a point. It just seems kinda weird to >accuse the guys who started all this of mere marketing ploys. The basic question that I have is: Why would IBM not refer to the 801 as a RISC in an article published 6 years ago and call the America (which, by almost every metric ever seriously considered is less RISCy) a RISC at its initial announcement? I can't think of any reason other than marketing hype. >Besides, >if the machine is as fast as they say, and if it doesn't qualify as a RISC >(under some hypothetical reasonable definition of RISC), then it would >seem some interesting (and undoubtedly amazingly inflammatory) conclusions >might present themselves... > Please don't interpret what I said as a knock of the design! After talking to a couple of presenters at ICCD, I was very impressed by both their design and their design philosophy. It's (going to be) a great chip. I just wish they had called the 801 a RISC and left it out (or at least not blared it) in the America -- why blow smoke on a foggy day! ;) I have a feeling that the RISC "conclusions" that you imply have already been reached by many design teams. Rick Miller 11012 Howland Drive Reston, VA 22091 The opinions expressed here are my own. Reply to rmiller@gmuvax2.gmu.edu
rcd@ico.isc.com (Dick Dunn) (10/19/89)
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: > From what I've read and heard, the reason for developing RISC was > *not* as an end in itself, but for speed. By reducing the cycles per > instruction more instructions per send would be executed. Only to do > that the instruction set was made smaller. Enter RISC. OK. This points out something which Colwell (in the uncited parent to Davidsen's article) also alluded to--the goal is not to produce a RISC; the goal is to produce a fast machine. RISC is a means to that end. But we do have to beware goal substitution. > I am a true believer in reducing the cycles per instruction, but I see > no virtue in having fewer instructions for any reason other than speed. > I am not offended by a chip with 1024 instructions, if it averages 1.1 > cycles/op... Nor am I, but that wasn't the point. The America processor, if you believe the _EE_Times_ article that started this (a notable "if"!), has substan- tially more instructions than, say, an 80386. It may be fast, but that's not a reduced instruction set. If they've made a new fast computer, let's call it a new fast computer and not slap the "RISC" label on it just because RISC is in vogue. In fact, it is interesting to examine the question Colwell mentioned-- namely, did the America work abandon the RISC approach? There's a lot to kick around there, but it's going to require that we stop talking as if RISC==fast. (Of course, if we're going to examine whether America con- stitutes an abandonment of the RISC approach, we'll need more info on America, including real price and performance data.) -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...No DOS. UNIX.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/19/89)
In article <1989Oct19.044615.7973@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: | Nor am I, but that wasn't the point. The America processor, if you believe | the _EE_Times_ article that started this (a notable "if"!), has substan- | tially more instructions than, say, an 80386. It may be fast, but that's | not a reduced instruction set. If they've made a new fast computer, let's | call it a new fast computer and not slap the "RISC" label on it just | because RISC is in vogue. Yes. I guess that one feature which separates (usually) RISC and CISC is hardwired vs. microcoded instructions. The America processor may be a RISC by that standard, I don't have enough info to guess. Then what do you call a CPU like the 486 or 68040 which seem to have a mix of hardcoded common instructions and microcode for instruction set richness? It was easier to identify the players when the characteristics were vastly diferent. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
geraldp@mentor.com (Gerald Page) (10/19/89)
According to the text "Computer Architecture, a Modern Synthesis",
by Subrata Dasgupta, John Wiley & Sons, 1989, most RISC processors have
the following 6 characteristics:
1. All instructions (operations) are register-register type with the exceptions
of LOAD and STORE, which access main memory.
2. All instructions (operations) consume a single processor cycle with the
possible exceptions of LOAD and STORE.
3. Fixed length, and simple, fixed format instructions that do not cross main
memory word boundaries.
4. Relatively few operations and addressing modes. <<<key words "relatively few"
5. The use of hardwired rather than microcoded control.
6. The use of instruction pipelining and the concomitant use of compilation
and delayed branch techniques... to eliminate pipeline distruption due to
branches.
As has been stated before on the net, RISC was developed for speed. Reducing
the instruction set is *one* of the ways that RISC achieves that goal.
According to tests done at Berkeley, compilers just aren't using all those
instructions anyway. One benchmark observed that 10 instructions (out of 360)
accounted for 80% of all instructions executed, 21 instructions for 95% of
executed instructions, and only 30 instructions acounted for 99% of executed
code. (Alexander & Wortman, 1975, on IBM System/360, using XPL language).elwin@athena.mit.edu (Lee W Campbell) (10/20/89)
In article <???>, davidsen@crdos1.UUCP (bill davidsen) writes: > From what I've read and heard, the reason for developing RISC was >*not* as an end in itself, but for speed. By reducing the cycles per >instruction more instructions per send would be executed. Only to do >that the instruction set was made smaller. Enter RISC. > > I am a true believer in reducing the cycles per instruction, but I see >no virtue in having fewer instructions for any reason other than speed. > ... Hear, hear! When I was taking courses in CPU architecture (about 2 years ago), the RISC philosophy was described thus: 1. Look at the CPU schematic and find the longest propagation delay. (i.e. what signal needs to trickle through the largest number of gates during 1 clock cycle). 2. Determine what instruction(s) that path is associated with. Are they essential, or frequently used instructions? If not, eliminate them! 3. Speed up CPU clock as fast as new (reduced) architecture can handle. 4. repeat the above 3 steps until you can't speed up architecture any more. Another motivation was that the machine that executed the microcode could go like hell, and if you could sell that to users with good compilers, it might make them happy. In doing this, some general principles were uncovered: (a) Instructions which must fetch from main memory and then use the ALU cause more delay than instructions which fetch from registers and then use the ALU. Therefore, eliminate a lot of fancy indirect-auto-this- and-that addressing modes. Instead, use a "load/store" architecture where all references to main memory are either register loads or register stores, and all ALU instructions use register operands. (b) Lots of registers are good! But not too many, because you need to save then when you change tasks. (c) 1 cycle per instruction is good, because it reduces the amount of "hidden registers" that need to be saved on interrupts, and makes it easier to restart an instruction, etc. (d) etc. Please feel free to insert your own favorite RISC principles. My only point is to emphasize what bill davidsen wrote: that the only purpose of RISC is SPEED. RISC is not some unifying philosphy, it is a collection of ad hoc techniques to make computation faster. Back when I was taking my course, we didn't even talk about multiple large onboard caches with wide (128 bits or more) busses to the instruction decoder, ALU, and register file. But obviously they are very useful and very effective in the Intel 860, 960CA, and 486 chips. One of the lessons of the 860 and 960CA is that it is possible to go considerably faster than 1 instruction per clock cycle. A major lesson from the 486 is that a big cache with a fat bus reduces the delay caused by fancy indirect-auto-this-and-that instructions, so you don't have to eliminate them, so you can get RISC-like performance with complex instructions! Since I believe the definition of RISC is a performance based definition, I consider the 486 to be as RISC machine executing a CISC instruction set! (A note: I believe it will always take less silicon area to build a "traditional" RISC load/store machine than to build an equivalent performance RISC/CISC machine. So I am not forcasting the death of SPARC or other load/store RISCS. But I don't believe they will wipe out major popular instruction sets such as 80386, 68030, VAX, IBM 370, etc. You'll just pay a little more for a CPU to execute those instruction sets). My, my, I do get windy in my old age... - Lee .===. \|/ - This Space - { Max } AKA Lee - Unintentionally - H-headphones /|\ Campbell - Left Blank -
khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) (10/20/89)
In article <1989Oct19.155752.13028@mentor.com> geraldp@mentor.com (Gerald Page) writes: > >2. All instructions (operations) consume a single processor cycle with the > possible exceptions of LOAD and STORE. I know of NO machine which performs singe floating point OPS in 1 cycle (some machines can achieve 1 fop/cycle when the pipes can be kept full). Are there counterexamples, or is #2 simply at variance with reality ? Keith H. Bierman |*My thoughts are my own. !! kbierman@sun.com It's Not My Fault | MTS --Only my work belongs to Sun* I Voted for Bill & | Advanced Languages/Floating Point Group Opus | "When the going gets Weird .. the Weird turn PRO" "There is NO defense against the attack of the KILLER MICROS!" Eugene Brooks
rang@cs.wisc.edu (Anton Rang) (10/21/89)
In article <126596@sun.Eng.Sun.COM> khb%chiba@Sun.COM (Keith Bierman - SPD Advanced Languages) writes: >>2. All instructions (operations) consume a single processor cycle with the >> possible exceptions of LOAD and STORE. > >I know of NO machine which performs single floating point OPS in 1 >cycle (some machines can achieve 1 fop/cycle when the pipes can be >kept full). Are there counterexamples, or is #2 simply at variance >with reality ? Lots of RISC systems implement floating-point using a coprocessor which runs asynchronously with the main (integer) processor. I think the idea here is not to let slow floating-point operations slow down the integer pipeline (but I could be wrong). Anton +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+
frazier@oahu.cs.ucla.edu (Greg Frazier) (10/21/89)
In article <126596@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) writes: >In article <1989Oct19.155752.13028@mentor.com> geraldp@mentor.com (Gerald Page) writes: >>2. All instructions (operations) consume a single processor cycle with the >> possible exceptions of LOAD and STORE. >I know of NO machine which performs singe floating point OPS in 1 >cycle (some machines can achieve 1 fop/cycle when the pipes can be >kept full). Are there counterexamples, or is #2 simply at variance >with reality ? First of all, yes, there are machines with single cycle (25 ns) FP adders and multipliers: %T An Integrated Floating Point Vector Processor for DSP and Scientific Computing %A D. Spaderna %A P. Green %A K. Tam %A T. Datta %A M. Kumar %J IEEE International Conference on Computer Design: VLSI in Computers and Processors %D October, 1989 %P 8-13 %C Cambridge, MA Second, the RISC concept specifically addressed integer engines and pulling memory closer to the processor. The six "characteristics of a RISC processor" previously mentioned are specifically the goals/features of the Berkeley RISC (which came first, the goal or the feature? :-), and second, a way to establish a category of processors. At the time RISC was being conceived, both at IBM and at Berkely, nobody was putting FP on the same chip as the processor. FP operations were "remote calls", if you will. Heck, caches weren't even on chip. The field of VLSI architectures is changing too fast to get religious about how to make a fast processor. Of course, the issue here isn't whether machines like the 860 and 960, which implement multi-cycle FP instructions, are fast - they are - the issue is whether or not they are RISC. And the answer is... who cares? The people who made RISC famous - Patterson et. al. - clearly stated a set of characteristics which they said defined a RISC processor. Coincidentally (?), the RISC I and RISC II processors displayed these characteristics. Now, if you want to re-define RISC to include machines like the 860, that's fine; I don't think anybody's patented the term, and I don't even know who used it first. But don't get upset when somebody tells you that so-and-so processor is/isn't a RISC - just keep in mind that the taxonomy is completely artificial, and all that really matters is how fast it goes. Greg Frazier *************************####################)))))))))))))))))) "They thought to use and shame me but I win out by nature, because a true freak cannot be made. A true freak must be born." - Geek Love Greg Frazier frazier@CS.UCLA.EDU !{ucbvax,rutgers}!ucla-cs!frazier
jde@unify.UUCP (Jeff Evarts) (10/26/89)
In article <1228@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > > IMHO too many people are concentrating on the number of opcodes rather >than the performance on real problems. Let's remember that RISC was >originally a solution to a performance goal, not some "natural >principle" which could be defended even if it had hurt performance. YES! YES! YES! >-- >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) >"The world is filled with fools. They blindly follow their so-called >'reason' in the face of the church and common sense. Any fool can see >that the world is flat!" - anon This is important. I head somebody shuddering a few months ago about the possibility of autoincrement/decrement on a RISC chip. Done properly, this could add a big 0 cycles to each instruction, and could be a big win. Unfortunately, anyone appearing on our doorstep today with a chip like that will be branded a CISC manufacturer adding too many "features" in silicon rather than in software. Keep in mind what the object was- improved performance, not philosophy and holy wars. Just another unsolicited opinion... -Jeff Evarts #include <std.disclaimer>
slackey@bbn.com (Stan Lackey) (11/14/89)
In article <126596@sun.Eng.Sun.COM> khb@sun.UUCP (Keith Bierman - SPD Advanced Languages) writes: >In article <1989Oct19.155752.13028@mentor.com> geraldp@mentor.com (Gerald Page) writes: >>2. All instructions (operations) consume a single processor cycle with the >> possible exceptions of LOAD and STORE. >I know of NO machine which performs singe floating point OPS in 1 >cycle (some machines can achieve 1 fop/cycle when the pipes can be >kept full). Are there counterexamples, or is #2 simply at variance >with reality ? The Alliant does fp in one cycle. In fact anything that uses BIT FP chips that cycles even up to speeds of 20MHz or more can do it, provided the operand passing is pipelined properly. -Stan
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/15/89)
In article <48135@bbn.COM>, slackey@bbn.com (Stan Lackey) writes: | The Alliant does fp in one cycle. In fact anything that uses BIT FP chips | that cycles even up to speeds of 20MHz or more can do it, provided the | operand passing is pipelined properly. Not having use an Alliant in several years, do they really do FP in one cycle? Or produce one FP answer per cycle. Your pipeline comment makes me think you mean the latter. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon