Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!cmcl2!rutgers!uwvax!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.fortran
Subject: `intrinsic' functions in forthcoming C standard
Message-ID: <13681@mimsy.UUCP>
Date: 22 Sep 88 01:42:50 GMT
References: <1028@amelia.nas.nasa.gov> <3957@lanl.gov>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 71

>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  (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 
	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 

	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