Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!orchid!atbowler
From: atbowler@orchid.UUCP
Newsgroups: comp.lang.fortran
Subject: Re: F8X comments
Message-ID: <11969@orchid.waterloo.edu>
Date: Wed, 2-Dec-87 08:44:37 EST
Article-I.D.: orchid.11969
Posted: Wed Dec  2 08:44:37 1987
Date-Received: Sat, 5-Dec-87 13:04:16 EST
References: <50500015@uxe.cso.uiuc.edu> <5774@j.cc.purdue.edu> <402@auvax.UUCP> <253@splut.UUCP> <9581@mimsy.UUCP>
Reply-To: atbowler@orchid.waterloo.edu (Alan T. Bowler [SDG])
Organization: U. of Waterloo, Ontario
Lines: 28

In article <9581@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>
>(Hah!  Most useful FORTRAN programs or subroutines require *some*
>change or adjustment to be brought from one environment to another:
>all those machine-specific constants in the engineering libraries
>are a good example.  Due to widespread use, many of these programs
>and libraries are carefully written so as to isolate the machine
>dependencies.)

This should be emphasized.  "portable" does not mean "machine-independant"
or "implementation independant" merely that it is less work to
change the existing code than it is to start over from scratch.

"implementation-independant" code is portable, the converse is
not true.  A useful concept (although perhaps not an easily measured one)
is the idea of a portabilty index for a program

    1 - (time to port program)/(time to rewrite completely)

machine independant code would have an index of 100%, completely
machine specific would be zero.  Clearly it is a good idea
to try to increase the index for any program you are writing
but there will be efficiency, convienience and other practical
tradeoffs that mean you usually settle for something less
than a 100% index.  The technique of explicitly dividing
a program into machine independant, and machine dependant parts
(either separate proceedures or parameters) can do a lot
to increase portability with little cost in efficiency etc.