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.