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 , 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 Brought to you by Super Global Mega Corp .com