Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!udel!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: Compilers taking advantage of architectural enhancements Message-ID: <2694@l.cc.purdue.edu> Date: 31 Oct 90 13:58:33 GMT References: <1990Oct9> <3300194@m.cs.uiuc.edu> <11922@ganymede.inmos.co.uk> <8424@scolex.sco.COM> Organization: Purdue University Statistics Department Lines: 75 In article <8424@scolex.sco.COM>, seanf@sco.COM (Sean Fagan) writes: > > In article <2661@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >This is still letting compilers drive the architecture. > > For most, if not all, people, this is fine. This is like the argument that we should not teach advanced courses. Why can one not get a terminal with a character set which is easily user programmable and downloadable? Most people are content to drive cars which they cannot control well, also. > Most of the con side of this argument takes an existing architecture, and > says, 'Well, if it had , we could do so much faster!' And that is a > valid point, and, possibly, can be added to a later revision of the > architecture. > > On the other hand, if you put a complex operation into the architecture in > the first place, one which ends up slowing down the machine as a whole, you > are *stuck* with that! In many cases, the operation is very simple, not complex. Do not assume that the current operations on the computers are even an attempt at the logically basic ones. This was the case in the early computers, when those designing them had a good understanding of mathematics. It is not the case now. Also, it may very well require more than a revision of the architecture to add a feature. If the architecture is designed with the flexibility to include that feature, yes. If not, it may be well-nigh impossible. > Consider, as always, a VAX versus a MIPS-based system. To get comparable > performance (CPU-wise, that is) on the VAX system, you have to go to the > high end of the series, because of the baggage the architecture has, which > ends up slowing down the entire system. Since it seems impossible to get enough information to take into account the hardware of the VAX, this may be the case. But the problem is not with the VAX design baggage, but with the lack of anticipation of the problems. > When designing a processor, it is not necessarily foolish to let the > compiler influence your decisions. I will, however, say that just sticking > to the here-and-now, and not considering the future, *is* a foolish thing to > do. > > >There are many useful > >constructs not in the present languages or architectures. Instead of trying to > >limit the architecture to what an automaton can use, we should be trying to see > >what those who think differently can find ways to use. > > Which is going to be faster: a machine which has your whiz-bang > instruction, but a clock cycle of 10MHz, and takes 32 cycles to execute the > instruction, or a system which has a clock cycle of 60MHz, and takes a total > of 75 cycles to execute an instruction stream to do the equivalent > operation(s)? I doubt that the difference is of that type. Many machines have a separate chip for floating-point calculations; if necessary, put complicated calcu- lations on that chip, or even another one. But my complaint is about operations which are very simple conceptually, and even simple at the nanocode or picocode level, but which are quite difficult to do in software. Also, operations which would be in the hardware if it were not for the lack of provision in software. How much harder would it be to have simultaneous quotient and remainder in the division hardware? How hard would it be to have a buffer-empty user-processed exception? These exceptions occur on cache or other memory faults, not subject to user control. In some cases, the difference would not be between 32 and 75 cycles, but between 2 and 75. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)