Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!pur-ee!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: Bandwidth and RISC vs. CISC Message-ID: <1262@l.cc.purdue.edu> Date: 26 Apr 89 12:44:05 GMT References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> Organization: Purdue University Statistics Department Lines: 96 In article <288@ctycal.UUCP>, ingoldsb@ctycal.COM (Terry Ingoldsby) writes: > In article <423@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes: > > "Compilers can do optimizations", I hear the yelling. This is another > > interesting phenomenon - reduce the complexity in the CPU so that the > > compiler must do all these other optimizations. I have also now seem any > > indications that a compiler can to anywhere close to an optimal job on > > scheduling code or pipelining. Even discounting the NP-completeness of > > just about everything, theoratical indications point the other way, > > especially when the compiler has to juggle so many conflicting constraints. > I am quite naive on this subject (but that won't stop me from throwing in my > two cents worth :^)), but it seems to me that if we still programmed mostly > in assembler, then CISC would beat RISC. I did a lot of programming of the > 8086 using assembler language, and I became (painfully) aware of some of the > unusual instructions, and the difference the choice a a particular register, > or way of doing something would make on overall performance. By skillfully > picking my instructions, I could improve performance *significantly*. On the > other hand, I can't imagine any compiler (apologies to the compiler writers) > smart enough to have figured out what I wanted to do, and to choose the > optimal instructions if I had coded the algorithm in a high level language. No apologies are due to the compiler writers. Rather, criticism is due to them for the arrogance they took in leaving out the possibility for the programmmer to do something intelligent. The HLLs are woefully inadequate, and I would not be surprised that the ability to do intelligent coding using the machine capabilities may be destroyed by learning such restrictive coding procedures first. You are far less naive than those gurus who thing they know all the answers. > In fact, I suspect that a lot of the weird instructions were never used by > compilers at all. This means that compilers often generate RISC code for CISC > machines (ie. they use the simplest instructions they can). You are so right. I have no trouble using these not very wierd instructions to do what the compiler writer did not anticipate. Nobody can anticipate all my needs, but nobody should say that he has given me all the tools, either. As far as the difficulty of using machine language, I know of no machine as complicated as a HLL, although some may be getting a little close. The present assembler languages are another matter, though, and unnecessarily so. > On the other hand, I can see that while a RISC processor programmed in assembler > might not be quite as quick as an expertly assembled CISC program, the compiler > has a reasonable chance of generating a good sequence of instructions. At > least it doesn't have to ask questions like: > 1) If I use register A for this operation, the next 10 instructions will > be quick, but > 2) would I be better to not use A, use B (slow) and wait until a really > critical set of instructions comes up to use A. > Even if your compiler is brainy enough to figure that out, there is almost > no way it can recognize that the algorithm I'm performing is a Fast Fourier > Transform. It will generate the code to perform it instead of using a > (hypothetical) FFT CISC instruction. I have run into situations where the number of possible programs is well into the thousands, at least. In many cases I can see that using some operations cannot pay unless those operations are hardware. How is the programmer going to write the program? Those who want it to be machine independent make things difficult. A good example of using CISC versus RISC is division, with a quotient and remainder. Some RISC machines do not even have this. Now I suggested to this group that the instruction be modified to allow the programmer to specify which quotient and remainder are to be used as a function of the signs. This is trivial in hardware, and probably would not extend the time by more than a small fraction of a cycle, although three conditional transfers are involved. The point is that they can be made while the lengthy division is taking place by the division unit. Another example is floating point arithmetic. The RISCy CRAY, on problems with rigid vectors, will run rings around the CYBER 205 in single precision floating point (around 14 digits). If we now change to double precision, we not get a time factor of about 15 in favor of the CYBER. Many problems in which non-rigid vectors are appropriate also favor the CYBER. Considering the cost of the CPU relative to the rest of the computer, I would suggest VRISC as the profitable way to go. But we need input from people like Terry and me about the apparently crazy instructions which will speed up throughput. > My point is that since almost everything is written in high level languages > today, they are better suited for RISC. For applications that still use > assembler (eg. control systems) CISC makes sense. Must we only use tools that would appal an artist? Programming is an art; artists do not learn by filling in the squares with numbered colors. > But what do I know?? More than the HLL gurus. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)