Gerhard Fiedler wrote:
> You were talking about intent. For a normal library, the compiler
> doesn't know about intent. For a library with a standardized interface
> (for example, the C++ STL) the compiler does know about intent.

I think you guys are talking past each other.  I think what Gerhard is
trying to say, but not doing a good job of it, is that he wants things that
look like library calls but that are really intrinsic functions that the
compiler understands natively.  The compiler would completely know the
intent of these functions and would be free to write in line code, call a
runtime library function, or optimize the "call" in any other way it sees
fit.  It could even eliminate it altogether if it could somehow detect that
results are never used, for example.

I think Sergio is saying is that this would be a great deal of work to add
that kind of knowledge into the compiler about common functions.

There have been cases where this was done, but naturally they are scarce
given the considerable compiler development required to support them.
First, most languages already have a set of intrinsic functions for basic
low level operations.  Bit shifts in Pascal are done that way, for example.
The LSHFT and RSHFT functions are known to the compiler and don't cause
library calls in most implementations.  My Pascal front end detects them and
a number of other intrinsic functions and writes out their resulting code.
LSHFT and RSHFT result in the << and >> operators if the result is written
in C.

Another case I remember is Silicon Graphics built in a few of the key
graphics calls of GL into their compiler.  Graphics functions are often
speed-critical since they can easily be executed millions of times while a
user is waiting for instant response.  A few of the GL calls were mapped
directly to I/O operations on their proprietary hardware and could be just a
few instructions.  A true call would have added at least as much overhead as
the target instructions, and would have prevented the compiler from doing
any optimization.

All in all I think intrinsic functions should be limited, especially when
common names are chosen.  It's dangerous to have a lot of reserved names in
a namespace the user can also create symbols in.  Of course you don't want
to have keyword bloat either, and the inline function syntax is convenient
for expressing a lot of things.  So as with everything, its a tradeoff.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist