Re: What is the FORTRAN for ?

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

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