Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!lll-crg!gymble!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.lang.c
Subject: Re: Compiler Specific Operators
Message-ID: <2364@umcp-cs.UUCP>
Date: Sat, 12-Jul-86 01:58:19 EDT
Article-I.D.: umcp-cs.2364
Posted: Sat Jul 12 01:58:19 1986
Date-Received: Sat, 12-Jul-86 07:20:53 EDT
References: <1825@uw-beaver>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 89

In article <1825@uw-beaver> golde@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@umcp-cs		ARPA:	chris@mimsy.umd.edu