Compiler Specific Operators

[Helmut Golde]

.
	What do people think about allowing compilers to have their own
compiler/machine specific operators, in a standardized format.  I think
it might be very useful to allow a compiler to have a non-portable operator
to do something that might be very efficient in machine code, but is not 
provided for by C.  

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

These would of course be usable as part of an assignment operator such as:

a $rol$= 5;	/* rotate a left 5 bits */

These instructions are provided by MANY processors and are a pain to
emulate in C.

2. Fast string/buffer routines.

Some processors provide a very fast instruction(s) for copying data from
one address to another.  Providing built-in ternary operators for this
would be convenient in some cases:

   d $copy$ s : n ::= given that s and d are both <type> pointers,
                      copies n <type>s from s to d.
		      (produces the value d)

   one could then write
#define memcpy(d,s,n) ((d) $copy$ (s) : (n))
   and
#define strcpy(d,s) ((d) $copy$ (s) : strlen(s)+1)

etc.

3. Built in math functions

If the processor has more than the standard +,-,/,* operators (esp. for 
floating point), it would be more efficient to have built it operators
that to perform function calls.  Things like:

$pow$, $sin$, $exp$, $log$, $atan$, etc.

#define's could make these quite portable without sacrificing the speed
advantage.


Well, what think you?  Worth it or not?

-----------------------------

Peter Golde