Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mcnc!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!gl8f
From: gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.lang.misc
Subject: Re: What is the FORTRAN for ?
Keywords: Fortran, design, code
Message-ID: <1990Jul31.005613.941@murdoch.acc.Virginia.EDU>
Date: 31 Jul 90 00:56:13 GMT
References: <164@kaos.MATH.UCLA.EDU> <4922@munnari.oz.au> <1990Jul30.180439.26627@esegue.segue.boston.ma.us>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 52

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.

Actually, this "weakness" can be solved by a smart linker.

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

Right. It's a bit silly to expect the compiler author to support any
possible hardware instruction and any possible piece of convoluted
code that might use that instruction. However, if you have a list of
things you want done fast, then write a set of HLL subroutines that
accomplish these things. (NINT() is a Fortran intrinsic already, for
example.) This is your portable library. Then for each architecture
with a smart linker, write the necessary inline assembly files and
link appropriately. (For NINT(), the vendor's Fortran should do it for
you.) I note that the MIPS linker, Sun's linker, and gcc all have no
problems doing this efficiently. The subroutine linkage gets optimized
away and you are left with only the single, efficient instruction.

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

You have to have list of these primitives somewhere, because your
language is going to need either operators or functions which
accomplish your tasks. That is, unless you want a mind-reading
compiler that is a wizard with instruction sets. Your little portable
routines define "Herman's Lovely Language", and things can run
everywhere at top speed.

So, in summary, this is how you do what you want, today, with today's
HLLs. Doing it this way is much easier than designing your own HLL,
which you have declined to do.

--
"In fact you should not be involved in IRC." -- Phil Howard