NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/fortran/3240

Text File | 1992-08-27 | 4.3 KB | 108 lines

Newsgroups: comp.lang.fortran
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: Small Language Wanted
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <H.3lvmyc56w&[e-mail]> <[e-mail]>
Date: Thu, 27 Aug 1992 21:41:04 GMT
Lines: 96

[e-mail] (Marc Roussel) writes:

>In article <H.3lvmyc56w&[e-mail]> [e-mail]
>writes:
>>In <[e-mail]>, "John E. Davis" writes:
>>> In addition, C has nothing equivalent to Fortrans **
>>> operator nor does it have complex types.
>>The differeces between code the compiler generates and
>>the one that is linked as a library or inserted by the
>>preprocessor.
>
>     That is a big difference!  Consider the following Fortran program:
>
>      integer i
>      double precision a,b
>      a = 4.2
>      b = 9.3
>      i = 10
>      write(*,*)a**i,a**b
>      END
>
>     The compiler, faced with such a program, examines the types of the
>arguments and generates completely different code to do the two
>exponentiations; certainly, one calculation can be expressed exactly in
>terms of multiplications while the other cannot.  It may be more
>efficient or more accurate to do it one way or the other and the
>compiler can choose a calculation method which reflects current thinking
>on this sort of problem.
>     Now consider an equivalent piece of code, written in C:
>
>     void main(){
>     int i;
>     double a,b;
>     a = 4.2;
>     b = 9.3;
>     i = 10;
>     printf(pow(a,(double) i),pow(a,b));
>     }
>
>(You'll forgive me, I hope, for getting the C idiom slightly wrong.
>The one manual I have at hand right now is less than entirely helpful on
>several trivial details.  In particular, I'm not at all sure that the
>cast of i to double is entirely kosher, and I think that printf wants a
>format specification.  In any event, you get the general idea.)  Can the
>compiler play the sorts of tricks which the Fortran compiler was free to
>do?  I don't think so.

Well, you are wrong.

>pow() being a library routine, I don't think it
>would be good form (or standard-conforming) for the compiler to guess at
>the programmer's intent and to do anything more than to leave the
>reference to be resolved by the linker.  After all, until the library is
>linked in, in principle the compiler knows nothing about any function
>but perhaps its prototype.  This particular library function
>expects (I think) two doubles (floats?) and must be passed these.
>That's all there is to it.

No, in principle if the library function in question is a *standard*
library function, then its implementation is just a part of the
compilation system. When the compiler sees #include <math.h>, it can
    - read /usr/include/math.h
    - read foobar.xyzzy
    - insert the appropriate declarations without reading any file.

Furthermore, when it sees

    pow(a,i)

in your code, and "i" happens to be an integer then it can emit code to
    - call the standard pow() function after convertin
      i to a double
    - call a special function the calculates doubles to
      integer powers
    - calculate the exponentiation using inline code.
Ie. it can make EXACTLY the same optimizations that Fortran compilers
make when they see a**i.
In other words, the _ONLY_ differences between an operator and a function are
    (1) the syntax is different
    (2) for the function, you should include the appropriate header file
        before using it.

>     In my opinion, what C lacks to be able to handle these things
>correctly is any concept of a "built-in" function.  Fortran knows to
>treat sin(a) and sin(x) differently if a is real and x is double
>precision because knowledge of these primitive functions is built into
>the compiler.  C can't do anything like this because of its design.

Yes it can.
Any function that is part of the standard library is a "built-in" function.

--
Fergus Henderson             [e-mail]
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!