Xref: utzoo comp.compilers:1090 comp.lang.misc:5259
Path: utzoo!attcan!uunet!husc6!spdcc!esegue!compilers-sender
From: bart@videovax.tv.tek.com (Bart Massey)
Newsgroups: comp.compilers,comp.lang.misc
Subject: Re: What is the FORTRAN for ?
Keywords: Fortran, optimize
Message-ID: <1990Aug01.011253.6726@esegue.segue.boston.ma.us>
Date: 1 Aug 90 01:12:53 GMT
References: <1990Jul25.174153.16896@ecn.purdue.edu> <164@kaos.MATH.UCLA.EDU> <4922@munnari.oz.au> <1990Jul30.180439.26627@esegue.segue.boston.ma.us>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: Bart Massey <bart@videovax.tv.tek.com>
Followup-To: comp.compilers
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 68
Approved: compilers@esegue.segue.boston.ma.us

In article <1990Jul30.180439.26627@esegue.segue.boston.ma.us> cik@l.cc.purdue.edu (Herman Rubin) writes:
> This appeared in an article posted to comp.lang.fortran, and I believe it
> illustrates a point about the weaknesses of HLLs (The poster was referring
> to C at this point) and compilers.
> 
> In article <4922@munnari.oz.au>, ok@mudla.cs.mu.OZ (Richard O'Keefe) writes:
> 
> > 	double nint(double x)
> > 	    {
> > 		return ceil(x + 0.5) - (fmod(x*0.5 + 0.25, 1.0) != 0);
> > 	    }
> > 
> >      is all it takes.]
...
> I do not see how a compiler can recognize that the complicated body of code
> can be replaced by a single instruction and make that substitution. ...

I tend to like the GCC approach to all this a great deal.  For the above
program, the nint() primitive above might be coded something like

	inline double const nint(double const x)
	    {
	#ifdef	frobozzco
		double result;
		asm("\tfrobozz_nint\t%1,%0":"=f"(result):"f"(x));
		return result;
	#elif	foobarco
		double result;
		asm("\tfoobar_nint\t%0,%1":"=f"(result):"f"(x));
		return result;
	#else
		return ceil(x + 0.5) - (fmod(x*0.5 + 0.25, 1.0) != 0);
	#endif
	    }

Note that the above code generates a single inline machine instruction on
machines which support it, and otherwise generates the best sequence of
inline machine instructions it can.  This is as close as I've ever seen to a
"user-extensible code generator", and it seems to solve a large class of such
problems very well, at least IMHO, by shifting the burden of code generation
in specialized applications from the compiler designer to the application
programmer, the latter presumably having a better idea of what he/she wants
or needs.

Note also that in G++, one can even declare the standard C operators to be
implemented by such inline asm functions, and thus get, for example, maximum
efficiency from a C++ complex number package on a machine which supports
complex numbers directly in the FPU.

I've seen Mr. Rubin post on this topic before, and I would humbly suggest
that, if he would be so generous, he could benefit the computing community
greatly by generating a GCC-compatible header file containing a bunch of
these inline asm functions for the complicated numerical operations he feels
are important to optimize well, and for a number of common CPUs.  I know
that I, for one, would be very interested in the results of such an exercise.
For a similar exercise in complex FPU insn utilization, at least for a
single processor, see Matthew Self's "math-68881.h", distributed with GCC.

I look at GCC's "inline asm function" feature as a way to extend the semantic
primitives of the language, in a syntactically compatible way.  So far, it
seems to me to have worked pretty well.

					Bart Massey
					..tektronix!videovax.tv.tek.com!bart
					..tektronix!reed.bitnet!bart
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.