Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!ncis.tis.llnl.gov!lance.tis.llnl.gov!turner
From: turner@lance.tis.llnl.gov (Michael Turner)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <1406@ncis.tis.llnl.gov>
Date: 11 Apr 91 17:47:26 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <1991Apr5.172533.6717@agate.berkeley.edu> <9782@mentor.cc.purdue.edu> <7117@auspex.auspex.com>
Sender: news@ncis.tis.llnl.gov
Organization: University of California, Berkeley
Lines: 37

In article <7117@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>If the languages do not allow the user to communicate  the use of those
>>features of the CISC architecture which can make the object code considerably
>>faster, the compiler cannot take advantage of them.
>
>What about those features of the CISC architecture that don't make the
>object code *any* faster?  Methinks that's what a lot of people are
>complaining about here....

Guy Harris's example (if I remember correctly) was that no language he
knew of had semantics for retrieving both the integer quotient and the
remainder from a floating divide, the point being that both values are
usually available from any implementation of floating point divide, but
that the language stands in the way of getting them at the same time.
I think a fairly trivial ad hoc common-subexpression analysis could handle
this particular case.  I also don't see how this is a CISC/RISC issue--
if anything, one instruction that yielded both quotient and remainder
is more "RISC", than having two that did div and rem separately.

As for CISC-architecture features that don't appear to be faster than
using combinations of other native-code features, this gets slippery. 
Yes, those added 68020 addressing modes don't make it faster, but they
do make the corresponding code denser, which might reduce I-cache misses.
If implementing them used up space on the chip that would have been
wasted otherwise, then there has been some good done, and little harm
but for a possible slight decrease in yield.  I don't know that that's
the case with the 68020.  From what I'm hearing of the 68040, it even
seems doubtful.  But that shouldn't get in the way of my point: that
when you're designing an architecture for single-chip implementation,
at some point you've got a little left-over real estate to play around
with.  Maybe you can even (*gasp*) add some instructions.  If this be
treason, make the most of it, I say.

Just my arrogant, ignorant opinion, as usual.
---
Michael Turner
turner@tis.llnl.gov