Compiler Specific Operators

[chris at umcp-cs.UUCP]

In article <1825 at uw-beaver> golde at uw-beaver.UUCP (Helmut Golde) writes:
>What do people think about allowing compilers to have their own
>compiler/machine specific operators, in a standardized format.

The current ANSI C draft standard (or at least the last one I saw)
allows this in a different way, which I will explain later.

>I propose that the standardized format $op-name$ be used for these
>operators.
>
>I realize that these would be inherently unportable, but sometimes you 
>*KNOW* what you are doing will never be ported and you don't want to
>switch to assembler or write a vert inefficient function. 
>
>A couple of examples follow:
>
>1.  More bit-manipulation routines, such as:
>   a $rol$ b ::= rotate a left b bits
>   a $ror$ b ::= rotate a right b bits
>   a $bit$ b ::= value of b'th bit of a

(The last example is perhaps not so good: (a & (1 << b)) is both
equivalent and portable.)

>These would of course be usable as part of an assignment operator such as:
>
>a $rol$= 5;	/* rotate a left 5 bits */

This is not provided in ANSI C, as we shall soon `C'.  (Sorry)

>These instructions are provided by MANY processors and are a pain to
>emulate in C.
>
>2. Fast string/buffer routines.

[memory copy, fill, etc.]

>3. Built in math functions

An ANSI-conforming C compiler can implement memcpy(), log(), sin(),
etc. inline by `tricky' use of `define's.  This could be extended
to functions like `rol(a, b)'.  Here is an example of how this may
be implemented:

	/* extract from <math.h> */
	double	sin(double x);		/* declare the real function */
	double	_builtin_sin(double x);	/* and the compiler version */
	#define	sin(x)	_builtin_sin(x)	/* default to the compiler version */

	/* extract from user file */
	#include <math.h>
	...
		y = sin(x);
	...

which of course expands to

		y = _builtin_sin(x);

and the compiler is free to handle this as it wishes.  The draft
standard emphasises that

	#undef sin

guarantees that a function call, not an inline expansion, will be
used.

Note that this has some, er, `interesting' implications:

	#include <math.h>

	double
	subr(double (*fp)(double arg)) {

		return ((fp)(3.1415926535897932384626433832795));/* approx */
	}

	strange() {

		... subr(sin) ...	/* NOW what? */
	}

This seems to call subr(_builtin_sin).  The draft standard says that
because `sin' appears here without a following `(', it is not macro-
expanded; thus this in fact passes the address of the library function.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu