Re: What is the FORTRAN for ?

ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
Tue, 31 Jul 90 18:07:21 GMT

          From comp.compilers

Related articles
Re: What is the FORTRAN for ? cik@l.cc.purdue.edu (1990-07-30)
Re: What is the FORTRAN for ? preston@rice.edu (Preston Briggs) (1990-07-30)
Re: What is the FORTRAN for ? ok@goanna.cs.rmit.OZ.AU (1990-07-31)
Re: What is the FORTRAN for ? bart@videovax.tv.tek.com (Bart Massey) (1990-08-01)
| List of all articles for this month |

Newsgroups: comp.compilers,comp.lang.misc
From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe)
Followup-To: comp.lang.misc
Keywords: Fortran, design, code
Organization: Comp Sci, RMIT, Melbourne, Australia
References: <1990Jul25.174153.16896@ecn.purdue.edu> <164@kaos.MATH.UCLA.EDU> <1990Jul30.180439.26627@esegue.segue.boston.ma.us>
Date: Tue, 31 Jul 90 18:07:21 GMT

In article <1990Jul30.180439.26627@esegue.segue.boston.ma.us>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> 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);
> > }


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


Er, that's a FUNCTION, sir, not a macro (#define).
When a compiler sees a call to nint(), it will generate a procedure call.
(Yes, in C++ and gcc I could say "inline double nint(...) but I *didn't*.)


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


Nobody else is _expecting_ the compiler to do that. To start with, the
only reason that I gave C code for nint() at all is that some C compilers
ALREADY have it as a built-in math function but some haven't; I said
"here is what you can do if you haven't already got it".


I have commented before on the ".il" facility provided by the Sun compilers.
I would like to point out once again that they provide a comparatively clean
way of getting at any instruction you like from within C. Here's what we do
in this case. Suppose we have a machine running SunOS on which the way of
rounding a double precision float to integer format is
cvtdir <source>,<destination>
(supposing this saves me looking up manuals to find out what the instruction
is really called on a 68881) and suppose that the machine is otherwise like
a 680x0. I would write a .il file


# This file defines nint() using a hardware instruction
.inline _nint,8
cvtird sp@+,r0
.end


Then I would write in my C source code


#ifdef imaginary_sun_model
extern double nint();
#else
   double nint(x)
double x;
{
extern double ceil(), fmod();
return ceil(x + 0.5) - (fmod(x*0.5 + 0.25, 1.0) != 0);
}
#endif


Compiling this on the right kind of Sun machine, I'd do


cc -O myprog.c nint.il


Compiling it on any other kind of machine, I'd do


cc -O myprog.c


and I would have a program which exploited the 'cvtdir' instruction
IF THAT INSTRUCTION EXISTS but which ran just fine on a machine which
had no such instruction, without needing any assembly code hacking on
the latter machine. The .il approach *WOULD* substitute exactly the
right single instruction in the right places (the .il expansion pass
is smart enough to combine
movd _foo,sp@-
cvtdir sp@+,r0
to
cvtdir _foo,r0
so I do mean a single instruction).


Surely this is a good approach? We use abstraction to hide the machine-
dependent details. We have an operation which makes sense on its own
however it is implemented; the rest of the program uses it _as if_ it
were a call to a C function, and it may be implemented by a call to C
code, a call to assembly code, inline expansion of C code, or inline
expansion of assembly code.


The V.3/386 C compiler has a similar feature, although there the
assembly definitions are included in the C source code (asm functions).


This idea can of course be applied to Pascal or Modula-2 or Fortran
just as well as it can to C, and assembly code inserts are already
part of standard Ada.


--
ok@goanna.cs.rmit.oz.au
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.