Xref: utzoo comp.compilers:1089 comp.lang.misc:5254 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!ncar!ico!haddock!ima!esegue!compilers-sender From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) Newsgroups: comp.compilers,comp.lang.misc Subject: Re: What is the FORTRAN for ? Keywords: Fortran, design, code Message-ID: <1990Jul31.180721.4524@esegue.segue.boston.ma.us> Date: 31 Jul 90 18:07:21 GMT References: <1990Jul25.174153.16896@ecn.purdue.edu> <164@kaos.MATH.UCLA.EDU> <1990Jul30.180439.26627@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) Followup-To: comp.lang.misc Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 92 Approved: compilers@esegue.segue.boston.ma.us 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 , (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 -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.