Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!rose!ccplumb
From: ccplumb@rose.uwaterloo.ca (Colin Plumb)
Subject: Re: bizarre instructions
Message-ID: <1991Feb26.155558.4215@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <9102220245.AA14853@ucbvax.Berkeley.EDU> <1991Feb25.134714.23523@linus.mitre.org> <10244@dog.ee.lbl.gov> <1991Feb25.203629.5059@linus.mitre.org> <10278@dog.ee.lbl.gov> <61756@masscomp.westford.ccur.com>
Date: Tue, 26 Feb 1991 15:55:58 GMT
Lines: 57

joeo@tinton.ccur.com (Joe Orost) wrote:
>In article <10278@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>>	static __inline const double sin(double x) {
>>		double result;
>>		__asm("sin %1,%0" : "=f"(result) : "f"(x));
>>		return result;
>>	}
>>
>>I claim that if this appears in <math.h>, it *is* built-in to the
>>compiler, despite the fact that the compiler reads these rules from an
>>external file rather than having them embedded directly in its
>>executable.
>
>Not so fast.  Our C3Ada-68K compiler and our Fortran VII-3200 compiler has the 
>transcendentals built-in.  This means much more than just compiling the 
>calls inline.  Built-in means that:
>
>	1. Constant evaluation is performed at compile time:
>	   SIN(0.0) is replaced by 0.0, etc.

Not done by the above; you're one up.

>	2. Common subexpressions and loop invarient code motion is
>	   performed on these operations at compile time:
>	   SIN(A)   ...   SIN(A)  replaced by one call using a tempo.

Done by the above; that's what the "const" qualifier on the function does,
and after inlining, gcc can see that there are no side effects.  (I did
some experiments with a non-existent "foo" instruction... it works fine.)

>	3. Special-case optimizations are performed:
>	   A**0.5 -> SQRT(A)
>	   A**1.0 -> A

Not done by the above.  I can see how the A**0.5 is useful; I can't see how
A**1.0 is - do programmers often write this?

>	4. The compiler knows the argument profile for the routines.
>	   In Fortran, SQRT(2) gets a warning and is converted to SQRT(2.0).

Done by the above.  The prototype forces conversaion to the right type
(although silently; there may be a warning flag you can turn on).

>	5. The calls generate inline code.

Of course, this is done by the above.

So, the only advantage you have to built-in transcendentals are compile-time
evaluation of constant expressions and some special cases.

I don't deny their usefulness, but claim it's not tremendous, and the cost
of a more complex compiler is not zero.  If you support a cross-compiler,
I hope you worked hard to ensure you're doing target arithmentic and not
host arithmetic when evaluating transcendentals.  Numerically unstable
applications might die horribly otherwise.
-- 
	-Colin
