Xref: utzoo comp.compilers:789 comp.arch:13805 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!brutus.cs.uiuc.edu!apple!snorkelwacker!spdcc!esegue!compilers-sender From: colwell@multiflow.com (Robert Colwell) Newsgroups: comp.compilers,comp.arch Subject: Re: Compilers and RISC (was: '040 vs. SPARC) Message-ID: <1990Feb12.180813.6585@esegue.segue.boston.ma.us> Date: 12 Feb 90 18:08:13 GMT References: <8905@portia.Stanford.EDU> <160@zds-ux.UUCP> <1990Feb9.161153.4190@esegue.segue.boston.ma.us> <1990Feb11.040548.223@esegue.segue.boston.ma.us> <1990Feb11.221418.2634@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: colwell@multiflow.com (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 44 Approved: compilers@esegue.segue.boston.ma.us In article <1990Feb11.221418.2634@esegue.segue.boston.ma.us> pardo@june.cs.washington.edu (David Keppel) writes: >Somebody -- probably Wirth -- has commented that a huge portion of a >compiler's size and a huge number of its bugs come from the optimizer. >Althought I doubt the Berkeley people were making the tradeoff >consciously, I consider a *>>SIMPLE<<* hardware scheme a Good Thing if >it can replace a complicated software scheme and get nearly as good >performance as a software scheme. This hasn't been my experience at all. What I've found is that bad compilers have lots of bugs, and good ones don't. Good ones are those written by good people who know what they're doing. All else being equal, simple things have fewer bugs than more complicated things, but as usual, all else is NOT equal. Good compiler writers won't settle for mediocre performance, and they won't shy away from complex algorithms in the process. But this doesn't mean they'll end up with a buggier compiler, it means they have to earn their pay. So what? Hardware folks have been doing this for decades. >[I always thought that the Intel 432 was an extreme example of why helpful >hardware can be a bad idea. Bug-wise, consider the size of the errata list in >any modern CISC chip, and that according to a recent comp.arch posting there >are no known bugs in the current Moto 88000 chips. -John] ???Why is the 432 an "extreme example of why helpful hardware can be a bad idea"? And I have a problem accepting your "Bug-wise" sentence, too. If you really want to compare errata sheets of RISC and CISC processors and then draw some conclusion (an exercise I don't necessarily find meaningful) then you need to compare how long it takes each to get to zero errors. You can't just take a snapshot comparison and conclude anything. How many mask revs did it take Moto to get the 88K to a clean sheet? Even if we knew that, and we knew how long the (say) 68040 will take, it's hard to extrapolate from two data points. It would be fun data to kick around, though, if the micro makers would cough up the info. Tell 'em it's for usenet, they'll understand. :-) Bob Colwell ..!uunet!mfci!colwell Multiflow Computer or colwell@multiflow.com 31 Business Park Dr. Branford, CT 06405 203-488-6090 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.