Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <11489@mentor.cc.purdue.edu>
Date: 28 Apr 91 19:58:23 GMT
References: <9782@mentor.cc.purdue.edu> <4082@batman.moravian.EDU> <1991Apr28.154603.8003@rice.edu>
Sender: news@mentor.cc.purdue.edu
Lines: 56

In article <1991Apr28.154603.8003@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes:
> hrubin@pop.stat.purdue.edu (Herman Rubin) 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.  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?  
> 
> In Fortran, you might write
> 
> 	iq = f1 / f2
> 
> and a while later (during which f1 and f2 are not changed)
> 
> 	fr = amod(f1, f2)
> 
> The compiler could recognize, during value numbering, that an
> quotient and remainder of the same operands was being computed.
> During instruction selection (or perhaps peephole optimization),
> it could recognize that it could avoid the real2int conversion
> of the quotent by using the "hrubin" instruction.
> 
> Not everyone does these things the way I've described them, but many
> compilers can achieve the same effect, one way or another.

Any specific instance of this can be added to the compiler's ken, but
until it does, the compiler cannot take advantage of it.  The point is
that the compiler must be instructed to look for them.  As to what it
can do with such instructions, this depends very strongly on what the
hardware provides.

The real2int conversion still has to be done on most machines, and also
an integerize of real.  But suppose that the machine has integer hardware
comparable to floating hardware, and can also handle unnormalized floats.
Then one could put a shifted significand of f1 in a double register,
divide by the significand of f2, setting iq to be the quotient, and 
the remainder with the exponent of f2, and then normalized, as fr.
Now I wonder how many of the readers would think of doing it this way?
And how would the hardware designers recognize that putting the operation
in hardware might be a good idea?

The individual compiler might or might not see it.  The community definitely
would not.

Now, how would you write the code for doing a conditional transfer efficiently
on the next bit of a bit stream, which can be extended (usually by a subroutine
call) when necessary?  It is unlikely that one will know, without querying, just
where one is in the stream.  If you wrote the code, would someone else so
recognize it?
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)