maine@altair.dfrf.nasa.gov (Richard Maine) (06/06/91)
On 5 Jun 91 22:08:05 GMT, mroussel@alchemy.chem.utoronto.ca (Marc Roussel) said: Marc> I can see one possible legitimate use of EQUIVALENCE with Marc> different data types: to decide on the endianism of your machine ... Marc> Such diagnostic toolkits are probably the only legitimate use of Marc> equivalence across data types though (other than saving space). Marc> Anyone know any others? Sure, I can think of several others. I certainly agree that you deserve what you get if you splatter such non-standard machine-dependencies throughout your code. However, there are several situations where their use is just about the only workable solution to a problem, and others where they seem to be one of the better options. I believe that the solution to this quandry of needing the non-portable feature, while keeping the code reasonably easy to port is often to isolate the machine dependency to a set of small, well-documented routines. These routines may be very system-dependent, but are not usually difficult to port. The big portability problems arise when you have zillions of instances of the non-portable code throughout your program. This philosophy is more general than the case of non-standard equivalences discussed here. For one of the specific cases where I have used non-standard equivalences, I'll mention an application where I used them to improve portability in one sense. I wrote a set of subroutines that is widely used by many programs at our site to read and write our flight test data files. I needed these data files to be portable among the many different kinds of systems that we use here. The easiest way to do this is, of course, to write the data in text files. There are usually well-defined ways to transfer text files among all the relevant machines, even when the machines use different text representations ASCII vs EBCDIC, etc). Indeed, my subroutines do support a text format. However, the size and time penalties of using formatted i/o are unacceptable for many uses of the subject data. The penalties are usually around an order of magnitude in both size and time. The text files are most commonly used when sending data to other sites that we haven't made better arrangements with or for listing small segments to the screen or printer. Acceptable performance for many uses requires a portable binary format. Unfortunately, you cannot write portable binary files in portable Fortran. Anyway, I can't and I have studied the problem a fair amount; there are several *very* serious obstacles. My solution, as suggested above, is to write portable binary files in Fortran that has only a few small non-portable routines that need custom versions for each system. One of the routines, for instance goes something like subroutine putR8( value, buffer, byte) ... (among other things, declare the bufSize parameter). double precision value integer buffer(bufSize) integer byte c Value is an input double precision value in the system's native format. c It is converted (as needed) to an ieee 64-bit real in big-endian c byte order and stored in "buffer" starting at byte "byte". Actually, this isn't quite a fully accurate description of the routine, but it is enough to illustrate the idea. The routine is trivial to implement on most systems, often by use of non-standard equivalences to do byte-swapping and the like. I have working versions of the routines on our Elxsi, Sun, Iris, IBM RISC, IBM PC, VAX, and SEL/Gould systems. (Thank God all these systems do use 8-bit bytes and we don't anticipate any that don't; otherwise, the problem would be much harder). All systems can read files made on all of the others and transfered by binary ftp or binary Kermit in spite of some quirky differences in how their various file systems like to write files. (The SEL was the worst - yuck). File size and access times are acceptable. "Everybody" here uses the subroutines. I think the application is successful and is a justified use of non-standard equivalences. -- -- Richard Maine maine@altair.dfrf.nasa.gov