🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #6639

Re: Educating FORTRAN programmers to use C

#6639
From: Scott Daniels
Date: Wed, 10 Jan 1990 17:25
43 lines
3278 bytes
In article <16717@duke.cs.duke.edu> bet@orion.mc.duke.edu (Bennett Todd) writes:
>In article <15078@bfmny0.UU.NET>, tneff@bfmny0 (Tom Neff) writes that
>rewriting extant FORTRAN applications wholesale with C isn't necessarily
>a good idea. I agree entirely. FORTRAN was designed to support numerical
>programming well; it does this. It has a wealth of mathematical types
>and functions defined into the language. In particular, basically much
>of libm is known to the compiler, so a *good* implementation of FORTRAN
>can code it all inline, and perform compile-time optimizations that
>depend on knowing details about how functions are being called.

This has been one of the problems for C that the ANSI standard addresses.  
Original C was required to treat all library functions by invokation, just
in case the user decided to write his own function by the same name.  So much
for compile-time evaluation of the library.  Now the standard provides a clear 
way for the compilers to know whether the library function will be invoked, so
look for the top of the line new ANSI C compilers to start doing the kind of
aggressive unfolding and reorganizing that was previously only available to 
Fortran.  There were battles with the numerical analysts (unary plus, respect
all parens, ...) precisely because they believe that there will be C compilers
capable of supporting optimizations that will allow C compiler to compete with
or at least approach the speed of FORTRAN programs.

>C++ offers the possibility of extending the language at compile time to
>support numerical applications.
This is true, neither FORTRAN nor C provide the capability of extending the
language with a set of user functions which can get the same kind of analysis
as the system functions.  C++ provides some of this (much more than most 
languages), but the functional languages (I am particularly thinking of lml 
here) get closer to what you'd like than any of the more traditional languages.

The really impressive optimizations will probably come from some system that
allows properties of the resulting abstractions to be defined (as in Goguen's
work on attaching theories to views).  This work may eventually lead to a 
system which can attain (on a user type) the fabled optimization (which knocked
out a benchmark on a FORTRAN compiler):
	for i = 1,90
	    V = V + sin( PI / i ) ** 2 + cos( PI / i ) ** 2
became
	V = V + 90.0

since the compiler knew (heavens knows why) that sin(x)**2 + cos(x)**2 = 1.

-Scott Daniels		daniels@teklds.wr.tek.com
Technical Details
Message-ID: <1298@wrgate.WR.TEK.COM>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!fernwood!decwrl!ogicse!blake!milton!uw-beaver!zephyr.ens.tek.com!wrgate!teklds!daniels
References: <1016@sdrc.UUCP> <1990Jan6.003158.2039@aqdata.uucp> <1024@sdrc.UUCP> <167@metapyr.UUCP> <15078@bfmny0.UU.NET> <16717@duke.cs.duke.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!fernwood!decwrl!ogicse!blake!milton!uw-beaver!zephyr.ens.tek.com!wrgate!teklds!daniels
From: daniels@teklds.WR.TEK.COM (Scott Daniels)
Newsgroups: comp.lang.misc
Subject: Re: Educating FORTRAN programmers to use C
Summary: ANSI C provides compilers a chance at libm optimizations
Message-ID: <1298@wrgate.WR.TEK.COM>
Date: 10 Jan 90 17:25:53 GMT
References: <1016@sdrc.UUCP> <1990Jan6.003158.2039@aqdata.uucp> <1024@sdrc.UUCP> <167@metapyr.UUCP> <15078@bfmny0.UU.NET> <16717@duke.cs.duke.edu>
Sender: nobody@wrgate.WR.TEK.COM
Reply-To: daniels@teklds.WR.TEK.COM (Scott Daniels)
Followup-To: comp.lang.misc
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 43