Re: What is the FORTRAN for ? (Richard A. O'Keefe)
Tue, 31 Jul 90 18:07:21 GMT

          From comp.compilers

Related articles
Re: What is the FORTRAN for ? (1990-07-30)
Re: What is the FORTRAN for ? (Preston Briggs) (1990-07-30)
Re: What is the FORTRAN for ? (1990-07-31)
Re: What is the FORTRAN for ? (Bart Massey) (1990-08-01)
| List of all articles for this month |

Newsgroups: comp.compilers,comp.lang.misc
From: (Richard A. O'Keefe)
Followup-To: comp.lang.misc
Keywords: Fortran, design, code
Organization: Comp Sci, RMIT, Melbourne, Australia
References: <> <164@kaos.MATH.UCLA.EDU> <>
Date: Tue, 31 Jul 90 18:07:21 GMT

In article <>, (Herman Rubin) writes:
> In article <>, (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

Then I would write in my C source code

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

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

cc -O myprog.c

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


Post a followup to this message

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