Re: Help from fellow Fortran Users

From: Bob Lidral (l1dralspamba1t_at_comcast.net)
Date: 01/24/04

  • Next message: beliavsky_at_aol.com: "Re: can i view the code of a fortran exe file" 
    Date: Sat, 24 Jan 2004 01:50:39 GMT

    Charles Russell wrote:

    > "Jim Klein" wrote
    > > The presenter said Fortran at which the
    > > department head winced and commented that Fortran is no longer being
    > > taught and that we should be using a "modern" language or we will have
    > > trouble supporting the code.
    >
    > Am I wrong in thinking that "portability" in the C world, and even more so
    > in the C++ world, means only that the code can be ported with less trouble
    > than to rewrite it? Whereas I routinely use fortran written 20 or 30 years
    > ago that compiles and runs on my current box with no changes whatever. And
    > you can't beat a few decades of extensive use to squeeze out the bugs.

    Portability, for programs written in any language, depends on four
    things:

      1. characteristics of the task,
      2. suitability of the programming language to the task,
      3. willingness of the programmer to follow the language standard, and
      4. willingness of the programmer to write portable code.

    Compilers are good examples of tasks with characteristics that preclude
    portability. A compiler that generates code for an AXP platform is not
    portable to a Pentium platform -- or, it might run on a Pentium platform
    but won't produce code that will run on a Pentium. Even a compiler that
    generates code for a Pentium running Windows might run on a Linux
    platform but won't produce output files usable by the Linux system.

    Early versions of Fortran were good examples of programming languages
    that weren't portable. Among other things, Fortran 66 didn't have end
    of file detection or read from/write to memory. If the task at hand
    required either of those, programmers were forced to use some sort of
    workaround or the language extensions provided by their compiler
    vendor. This made it impossible to run programs written for one
    vendor's platforms on the platforms of any other vendor. At one place I
    worked, we even managed to pervert the Fortran 66 calling sequence to
    support pointers and pointer arithmetic -- definitely non-portable.

    Pascal had such a sloppily-written standard with so few features that it
    was impossible to write any kind of Pascal program that was both
    portable and did something useful.

    OTOH, C programs can be much more portable than Fortran programs written
    according to standards earlier than Fortran 90. C supports all sorts of
    features not supported in early Fortran standards (character variables
    not supported until Fortran 77, pointers, structures, etc.). However,
    many C programs are not portable because of dependence on a particular
    architecture or operating system, e.g., compilers, database
    implementations, etc., or due to other issues mentioned below.

    Some programmers are just so impressed with their own knowledge of the
    peculiarities of a particular language implementation that they insist
    on using non-standard constructs even when they're not necessary to work
    around inherent limitations of the language. The most obvious Fortran
    example of this is dependence on DO loops executing at least once, even
    for non-standard-conforming DO statements. Other non-portable
    techniques include use of the *<byte length> suffix for types (though
    that was sort of a de facto standard), knowledge of the internal
    representation of characters, and the use of EQUIVALENCE and COMMON to
    overlay different incompatible (according to the standard) variable
    types onto the same storage locations.

    Finally, even when a programer knows the standard well enough to write
    standard-conforming source code AND is willing to do so, there's the
    question of whether the programmer is willing to write portable code.
    For simple problems, standard-conforming source is portable; that is,
    it will compile without errors and will probably produce the same
    results (though be careful of floating point operations, especially
    comparisons).

    But some programs require interaction with the surrounding system (names
    of files & directories, KIND TYPE values, etc.). In most cases, these
    dependencies can be collected and isolated into a relatively few source
    files so that only a small part of the program needs to be rewritten for
    each different platform (include files really help with this). But a
    remarkable number of programmers seem to delight in spraying system
    dependencies (e.g., page size, disk block size, character set knowledge,
    etc.).

    Over the years, I've had to write portable code and port other people's
    code among several different systems and compilers. The machines had
    16-, 32-, 36-, and 60-bit words; 1's-complement and 2's-complement
    arithmetic; character sets included ASCII, EBCDIC, CDC Display Code,
    etc.; and I've lost track of all the compiler differences (e.g., "long"
    is 32 bits for the AXP/VMS C compiler but 64 bits for the AXP/Tru64
    Unix C compiler); etc. I've discovered the biggest problems with code
    portability are both language-independent:

      1. Programmers who aren't aware of the issues involved. This group
         includes most programmers. These can be programmers fresh out of
         college who've never used more than one vendor's platform or
         employees of one of the vendors (e.g., especially DEC, CDC, or
         IBM) who've never worked for anyone else and can't conceive of any
         other way to do anything.

      2. Programmers who just don't care about portability -- or, worse,
         seem actively opposed to it. This group includes almost all
         programmers. I don't know why, but even programmers who do
         understand some of the issues will just ignore them and become
         defensive -- or even belligerent -- when anyone, even their
         managers, asks them to follow portability conventions. Maybe my
         experience is statistically skewed. More likely, though, there
         are just a lot of arrogant programmers out there who think they're
         too good or too important to do maintenance or porting and who have
         no sympathy for us peons who get stuck with that work.

    It's certainly possible to write portable code in C and, once over the
    learning curve, even easier in C++. Since the Fortran 77 standard, it
    has even been possible to write portable code in Fortran.

    If you're seeing a difference in portability between Fortran and C code,
    there's a good chance that's the result of differences in age. Old
    Fortran programs that have been ported to several different platforms
    for 20 or 30 years may have had all of the non-portable code removed or
    made portable. Wait until the C programs are 20 or 30 years old and
    have been ported to and used on as many different platforms before
    commenting on comparative portability.

    Bob Lidral
    l i d r a l at a l u m dot m i t dot e d u

  • Next message: beliavsky_at_aol.com: "Re: can i view the code of a fortran exe file"

    Relevant Pages

    • Re: Integer types in embedded systems
      ... Notice the integer type I've used, ... compilers for 8-bit micros have an option for telling the compiler not ... Most C programmers these days are woefully ignorant, ... At least as important as portability, ...
      (comp.lang.c)
    • Re: Youre appointed as Portability Advisor
      ... Let's say you're appointed as the Portability Advisor for a multi-national company that makes billions of dollar each year. ... You're sitting there 100% aware that the Standard explicitly forbids you to write to member A of a union and then read from member B, but how much do you care? ... What _can_ cause problems tho is aspects of the compiler: ... If there was a consenus between many of the world's most skilled and experienced C programmers that a certain rule in the Standard were unnecessarily rigid, would it not be worth the compiler vendors' while to listen? ...
      (comp.lang.c)
    • Re: A question on Newtons Method
      ... >> I can't believe you'd advise a noob to use a compiler which is still ... > production codes and codes from textbooks. ... > The Fortran standard generally does not specify the required behavior ... >> another important class of hassle which most numerical programmers ...
      (sci.math.num-analysis)
    • Re: Numbers and truth values
      ... only say I'm happy I stopped using Fortran heavily before such standards ... illegal to change a constant and the compiler is still not required to ... such code as before, helping programmers spot errors. ...
      (comp.lang.python)
    • Re: Latest on Windoze Navy software
      ... > it had defined a proper string type like Fortran and Basic, ... Well, I haven't used Fortran since F77, but base don that your now ... but because programmers don't really care. ... many 1979 BSD 4.0 systems do you think had any compiler other than the C ...
      (comp.os.vms)