Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amelia!lemming.nas.nasa.gov!fouts
From: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.lang.fortran
Subject: Re: intrinsic functions, math operators (was: i++, i+=1, i=i+1)
Message-ID: <1031@amelia.nas.nasa.gov>
Date: 21 Sep 88 20:22:41 GMT
References: <1028@amelia.nas.nasa.gov> <3957@lanl.gov>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts)
Organization: NASA Ames Research Center
Lines: 62

In article <3957@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1028@amelia.nas.nasa.gov>, by fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts):
>>    which ANSI committee you are refering to (C?) The proposal is *not*
>>    for intrinsic functions, but for required library functions.
>>    Implementation left to the implementer.
>
>Look again.  There are a number of functions which the committee says
>the processor is allowed to optimize or expand in-line.  The rationale
>document recommends that the in-line expansion be passed to the processor
>as a macro in one of the default includes - but (as far as I know) this
>is not the _required_ way of in-line expansion.
>

Err, the draft standard actually allows in-line expansion of any known
function, including user defined functions, provided certain rules
(which I don't remember) are followed.  It also requires that this be
overridable.  GNU C and G++ (Gnu C++), for example, already have this
ability as a user option.  It is an attempt to give the (definitely
justifable) advantages of intrinsics while maintaining the ability to
override.

>Furthermore, if implementation were left to the implementor, _many_
>functions would be implemented by the compiler - they're easier to do
>that way (if you really want them to be optimized).

Well, maybe.  When I'm implementing a compiler, I try to stay as far
away from knowing semantics of called routines as possible, because
the techniques I use are easier to implement if they discover the
semantics on the fly than if they carry them around as imbedded
knowledge.  (Easier, but more expensive, when the semantics never
change, which is rarely.)

>  If I were writing
>a C compiler, I would certainly do pow() in-line.  What you claim is that
>the ANSI C committee is listing a group of required functions and that
>these are _required_ to be implemented in a library form.  I don't think
>this is true.
>

No.  I did not claim that the functions are _required_ to be
implemented as libraries.  You are deliberately confusing the converse
and inverse of a statement.  I claimed that the functions are required
to be present, and that the mechanism of implementation was undefined.
They may be implemented by inline generation by a knowledgable
compiler, by macros in standard headers (provided side effects are
correctly handled), or by libraries.  My reading of the draft shows
any of these to be allowed; provided that in all cases the user is
allowed to override the standard version with a private version.

Inline code generation is an allowable substitution in any event,
provided the compiler can correctly determine that the substitution
produces a semantically equivalent executable.  Hopefully it is only
ever done as a space/time tradeoff optimization.

(Creon Levit says:  "Oh yeah, the old space/time tradeoff.  Takes more
 space and more time.)

+-+-+-+     I don't know who I am, why should you?     +-+-+-+
   |        fouts@lemming.nas.nasa.gov                    |
   |        ...!ames!orville!fouts                        |
   |        Never attribute to malice what can be         |
+-+-+-+     explained by incompetence.                 +-+-+-+