Xref: utzoo comp.compilers:1084 comp.lang.misc:5234
Path: utzoo!attcan!uunet!snorkelwacker!spdcc!esegue!compilers-sender
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.compilers,comp.lang.misc
Subject: Re: What is the FORTRAN for ?
Keywords: Fortran, design, code
Message-ID: <1990Jul30.180439.26627@esegue.segue.boston.ma.us>
Date: 30 Jul 90 18:04:39 GMT
References: <1990Jul25.174153.16896@ecn.purdue.edu> <164@kaos.MATH.UCLA.EDU> <4922@munnari.oz.au>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: cik@l.cc.purdue.edu (Herman Rubin)
Organization: Purdue University Statistics Department
Lines: 30
Approved: compilers@esegue.segue.boston.ma.us

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 have not checked the code, but this points out what is wrong with the 
present HLLs and that compilers cannot be expected to overcome the problem.
If this #define were used, then this block of code would be inserted wherever
this is wanted, even if there is a machine instruction which does the job.

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.  One 
could put that one in, but another will arise, and another.  And these will
continue to crop up as long as the language primitives are restricted as
they now are.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue.  Meta-mail to compilers-request@esegue.