Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!lll-winken!iggy.GW.Vitalink.COM!widener!netnews.upenn.edu!vax1.cc.lehigh.edu!lehi3b15!batman!halkoD
From: halkoD@batman.moravian.EDU (David Halko)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Summary: division in compiler design
Message-ID: <4082@batman.moravian.EDU>
Date: 23 Apr 91 15:31:37 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <9782@mentor.cc.purdue.edu>
Organization: Moravian College, Bethlehem, PA
Lines: 56

In article <9782@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> In article <1991Apr5.172533.6717@agate.berkeley.edu>, doug@eris.berkeley.edu (Doug Merritt) writes:
> > In article <1991Apr4.125122.1@capd.jhuapl.edu> waltrip@capd.jhuapl.edu writes:
> > >	He observes that "Few compilers use any of the nifty instructions that
> > >	a CISC has."  I believe I read recently that RISC was based on the
> > >	observation that, in fact, only about 30% of the instructions in CISC
> > >	computers were used by compilers.  The rest of the instructions, for
> > >	all practical purposes, were just excess baggage.
> 			.........................
> > Anyway, the point is that even if compilers *do* use every possible feature
> > of a CISC, it still usually won't make the CISC s/w competitive with RISC
> > s/w. CISC cpus almost never put sufficient h/w optimization into the support
> > of the fancy instructions. (There are exceptions to this, of course, and I
> > haven't been watching the 030 and 040 to see how they do in this regard.
> > CISC may yet rise again, but not until after superscalar RISC has been
> > completely exploited.)
> 			.........................
> 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.  This IS the situation.
> For example, suppose there was an instruction, which could be effectively
> used, which would divide a float by a float, obtaining an integer quotient
> and a float remainder.  Now just how is the compiler to recognize that this
> is in fact wanted?  
> 			.........................
What do you mean how is a compiler suppoosed to recognize that this is wanted?

    AT&T came out with a DSP board which utilized neato CPU features in its
high level languages... since floating point multiply was so much faster
than integer multiply, it would take integers, convert them to float, do
the floating point multiplication, and convert back to integer again. Man,
talk about fast and nifty. This was all handled internally, inside the C
Compiler. It seems quite useful for integer division to do the same, here.
There were, however, some minor flaws in the Compiler which took away from
some of it's efficiency. I used to use global search and replace with specific
patterns to optimize the code I produced...

> There is, at present, no language designed to take into account the collection
> of "natural" useful hardware which the present users can find uses for, and
> which are far more expensive in software than in hardware.

I think it may be more of a question of "Are CISC features being fully realized by
compiler designers?"

I wonder if RISC architecture is all what it is cracked up to be. I work on 
a SUN SS1, and it is not all that much faster than a 3/60. Quite often, I
use the 3/60's we have instead. 
-- 
     _______________________________________________________________________
    /                                                                       \
   / "The use of COBOL cripples the mind; its teaching should, therefore, be \
  /  regarded as a criminal offence."           E.W.Dijkstra, 18th June 1975. \
 +-----------------------------------------------------------------------------+
  \  "Have you purchased a multi-   halkoD@moravian.edu  Have you booted your /
   \ media machine from IMS yet?"   David J. Halko       OS-9 computer today?/
    \_______________________________________________________________________/