chris@mimsy.UUCP (Chris Torek) (09/22/88)
>Marty Fouts: >>... The proposal is *not* for intrinsic functions, but for required >>library functions. Implementation left to the implementer. In article <3957@lanl.gov>, jlg@lanl.gov (Jim Giles) writes: >Look again. There are a number of functions which the committee says >the processor is allowed to optimize or expand in-line. The rationale >document recommends that the in-line expansion be passed to the processor >as a macro in one of the default includes - but (as far as I know) this >is not the _required_ way of in-line expansion. Largely so. But these are not `intrinsics' in two ways: They must either appear in the library, or appear to appear in the library; and they need not be recognised by the compiler. (In F77, for instance, `ABS' must be recognised by the compiler, since it may take the absolute value of either a REAL variable or an INTEGER variable, whereas in dpANS C, one must use `fabs' for float and double variables.) >Furthermore, if implementation were left to the implementor, _many_ >functions would be implemented by the compiler - they're easier to do >that way (if you really want them to be optimized). The most likely implementation, which is used in both GCC and SunOS 4.0, is to have `#define's in <math.h> (and perhaps elsewhere) that look something like this: #define fabs(x) __builtin_fabs(x) The reason for this is that, while the dpANS allows #include <math.h> f() { float x = fabs(-1.0); ... to reduce the assignment to `x = 1.0', it also requires that, after `#undef fabs', a `function' version be used. Moreover, code such as #include <math.h> double ident(double x) { return x; } f() { g(fabs); g(ident); } /* `map' is pointer to function, despite appearance to contrary */ g(double map(double x)) { printf("%f\n%f\n", map(-1.0), map(1.0)); } /* in `old c' g is g(map) double (*map)(); { printf("%f\n%f\n", (*map)(-1.0), (*map)(1.0)); } */ is legal, and it is fairly hard to compile this correctly without having `fabs' in a library and using a macro like the one shown above. Essentially, what the dpANS says is that if you, the programmer, write your own version of the `library' functions, you have not written a strictly conforming program, and a compiler that produces absolute values even though your `fabs' produces `fabulously signed' numbers is still correct. Hence the compiler is *allowed* to optimise calls to fabs or pow, but not *required* to do so (but then, neither is an F77 compiler required to optimise anything). (The de facto situation in `old C' is that if you did perform such optimisations, only a few peoiple would complain---notably those who think that `fabs' means `fabulously signed' :-) .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
jlg@lanl.gov (Jim Giles) (09/23/88)
From article <13681@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > Essentially, what the dpANS says is that if you, the programmer, write > your own version of the `library' functions, you have not written a > strictly conforming program, and a compiler that produces absolute > values even though your `fabs' produces `fabulously signed' numbers is > still correct. [...] This is _exactly_ what I meant when I said that the new standard was declaring some functions to be intrinsics. The are making a list of functions which the user cannot redefine in a portably reliable way. The compiler (or some other tool on the p[ath) is allowed to treat these functions in a different way - and users who try the redefine these are doing something non-standard. This is also exactly what I said was _desireable_ for the committee to do. It spells out explicitly which functions cannot be redefined so that the user can write portable code (by avoiding those names). The old de-facto C standard was not as portable because of this omission. Why is it when I say something, every jumps down my throat. When someone else says the _same_ thing it's greeted as a 'true revelation'. J. Giles Los Alamos