Re: Compilers and RISC (was: '040 vs. SPARC)

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

Return to the comp.compilers page.
Search the comp.compilers archives again.