phipps@garth.UUCP (Clay Phipps) (06/01/90)
In article <6553@gollum.twg.com> dwh@twg.com (Dave W. Hamaker) wrote: >firth@sei.cmu.edu (Robert Firth) wrote: >>In article <Z-C34+4@xds13.ferranti.com>, >>peter@ficc.ferranti.com (Peter da Silva) writes: >>> >>>Well, I just had to figure byte order for a machine >>>with only a Fortran compiler and no docs. >>>here's the fortran code, [...]: >>> >>> INTEGER*4 A >>> CHARACTER*4 B >>> EQUIVALENCE (A,B) >> >>This is surely neat code, but it ain't Fortran. > >This illustrates one of my pet hates about standardization: >the tendency to pursue portability and safety at all costs. >The very first time I used a Fortran77 compiler, >I had to give up trying to use Fortran to solve my problem entirely, >precisely because the compiler enforced the above restriction. My recollection is that soon after the FORTRAN 77 standard was adopted, there was a strong incentive to support dusty-deck programs written for the FORTRAN 66 and de facto FORTRAN IV languages. If your first use of FORTRAN 77 was well into the 1980s, I suppose that the compiler-writers for some environments could get away with not supporting the dusty decks; it would simply be a matter of how many sales the compiler vendor (if commercial) was willing to walk away from. >I think I wanted to save space >by storing small integers in character variables. >[...] I am utterly convinced that sometimes an efficient solution >is better than one which is less efficient but portable. I think this is close to being a tautology. This is particularly important if the solution is known in advance to be operating at the limits of the available system, which may be a huge investment (e.g.: a large mainframe). >The fact remains that I have found Fortran to be a useful tool at times. >It is also true that as Fortran has evolved, >it has tended to become less useful to me, >precisely because things have been removed and/or restricted in the language >implemented by compilers because of safety/portability concerns. Probably the strongest reason that some compilers strictly implement the applicable standard is to take advantage of simplifying assumptions that the standard allows. The simplifying assumptions may enable certain optimizations to be performed that would otherwise be disallowed. I remember a situation (at a previous employer) where a very important customer insisted on being able to "overindex" some arrays (e.g.: "A(10000,1)" was expected to be the same location as "A(100,100)", for an array declared "A(100,100)"; the former access is not allowed by the FORTRAN 77 standard), which created problems for the automatic vectorizer. The solution was to provide a compiler flag which ordered the compiler to allow such references, but it disabled some potential vectorization, and was a source of aggravation in general. >Peter could still have used the compiler to solve the problem >if the compiler had warned him that the usage was non-standard. Of course, this combines all the complexity of supporting the standard, with all the complexity of supporting the nonstandard usage. My experience is that when Marketing or Sales comes to Engineering and says that a big sale depends on support of a nonstandard feature of a language, the compiler people are instructed to provide support for that feature, pronto. The argument from compiler people that "[the insisted-upon feature] is nonstandard" is usually quickly countered--pointedly--by management with words to the effect that "the reason we pay you a salary is to solve problems like that". -- [The foregoing may or may not represent the attitude or style of my employer, ] [ who is identified solely to allow the reader to account for personal biases.] Clay Phipps Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327 UseNet (Intergraph internal): ingr!apd!phipps UseNet (external): {apple,pyramid,sri-unix}!garth!phipps EcoNet: cphipps