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