On Thu, 9 Jul 2009, Olin Lathrop wrote:

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

Thank you Olin, I had considered that Gerhard was maybe talking about 
intrinsic functions. Originally I thought he was saying that the language 
should allow you to give the compiler enough info on a nonmal 
(non-intrisic) function to be able to use it the same way. Then I cottened 
on to the fact that what he was actually saying is that if a compiler 
could analyse all the source (including that of the libraries) then it 
would be able to extract all the info needed to make a non-intrinsic 
function intrinsic.

Friendly Regards
Sergio Masci
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist