maine@elxsi.dfrf.nasa.gov (Richard Maine) (09/02/89)
In article <1073@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: > What I meant was: do I HAVE to rewrite something otherwise it'll perform > differently ? The answer seems to be 'No, you don't have to if you don't > need new features'. That's enuff for me. > In this respect F77 broke badly F66 with the story of zero-trip loops > vs. one-trip loops. Although this is a common misconception, it isn't true. By the FORTRAN 66 standard, the code DO 100 I = 1 , N .... 100 CONTINUE was illegal if N was less than or equal to zero. The standard did not specify a one-trip loop. FORTRAN 77 made this legal and specified the zero trip interpretation. Since legal FORTRAN 66 programs did not use this construct with N<=0, they were not affected by the FORTRAN 77 specification. Now it is true that IBM's FORTRAN 66 compiler did this as a one-trip loop, but contrary to popular perception, the FORTRAN 66 standard was defined by the document published by ANSI rather than by IBM's compiler manual. It is also unfortunately true that innumerable programmers blithely ignored the standard and used the one-trip interpretation. Those programmers had code that broke badly (and forced many vendors to provide compiler options to support the broken codes). > Also it gave us a very difficult transition from > Hollerith characters to the new character type. Life IS difficult > sometimes. Yes, this one was difficult. And a lot of codes have not yet changed, but still use the Hollerith. Though even here, there was a strong correlation between the "cleanliness" of the code and the difficulty of the change. Code with complicated EQUIVALENCE or COMMON relationships or with variables used interchangeably as Holleriths and numerics was/is very hard to convert (and was often non-portable in FORTRAN 66 anyway because of different character and word sizes). Code with "clean" Hollerith usage was usually pretty easy to convert to at least work in FORTRAN 77, although the converted code was often more complicated than new code in FORTRAN 77 would presumably have been. The correlation was not perfect. Some ugly codes were ugly in ways that converted (to ugly FORTRAN 77). Some clean codes were difficult. But I feel safe in claiming that there was a correlation. So the moral is: 1) Codes that adhered to the standard, paid attention to FORTRAN 66 portability, and were "cleanly structured" tended to convert easily to FORTRAN 77. Since FORTRAN 77 compilers tended to support the Hollerith extension as a compatability option, many of these codes ran correctly with no changes at all. 2) Codes that violated the standard, used non-portable FORTRAN 66, or had poorly-structured design tended to have varying degrees of difficulty converting to FORTRAN 77. Some never were successfully converted. 3) And then I know of a few cases of codes that had not correctly worked in FORTRAN 66, but the bugs were not noticed until they came up and were fixed in the conversion process. There may not have been many of these, but I know there were some. Sound familliar? I think you will be safe in making simillar predictions about FORTRAN 77 to Fortran 8x conversion. Most (alas, not all) of my own FORTRAN 66 codes converted relatively easily to FORTRAN 77, though I later did substantial revisions (at my option) to take advantage of new FORTRAN 77 features. I expect my FORTRAN 77 codes to convert easily to Fortran 8x, though I will probably do some substantial revisions to take advantage of new Fortran 8x features. -- Richard Maine maine@elxsi.dfrf.nasa.gov [130.134.1.1]