[comp.lang.fortran] Non-standard equivalences

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