Re: =?utf-8?B?5Zue5aSNOiBPbmUgcXVlc3Rpb24=?=

[Craig Burley <burley at gnu dot org>]

>I am confused about some terms like "endian-ness", "RISC-based machines"
>and "vice-vesa", could you give me a concise explain. so many thanks.

Forget about "RISC-based machines", it's not really relevant.

"Endianness" refers to the which "end" of a number is "first" when
it cannot fit into one "digit".  If you think of a "digit" as a
normal, human decimal digit instead of the more-typical computer-based
8-bit byte, there are two "natural" ways to represent the number
"one thousand, two hundred and thirty-four":

  1234  ("Big end" first, or "big-endian")

  4321  ("Little end" first, or "little-endian")

Note that terms like "first" are kind of subjective anyway -- in this
case, they refer to the left-to-right ordering of most Western writing
(like English), even though the Arabic numbering system, which uses
right-to-left ordering of digits, is used.  So the problem isn't just
with computers -- they just spread the disagreements faster than humans.

And how multi-digit numbers of various types are "written", or appear,
in the computer's main memory is usually directly reflected in any
unformatted files produced by, e.g., Fortran compilers on the system.

That's true mainly because there wasn't early industry-wide agreement
on the order of the digits (the endianness), which isn't as stupid as
it sounds, because there wasn't much agreement on other formatting
issues.  In particular, lots of different formats existed for
floating-point values (whereas there's long been a fair amount of
agreement on the formatting, but still not the endianness, of integers
-- that is, two's-complement has predominated for a long time now).

But it's also true because taking the time to swap the order of bytes
(digits) every time a number is read from or written to disk is
not a popular thing to do for "unformatted I/O", which is supposed to
be *fast*, not pretty nor portable.

And taking that extra time for byte-swapping would effectively "punish"
one entire class of machine -- the class that had the "wrong" endianness.
So anyone working on one class of machine would tend to say "I'd love
it if everyone standardized on one format -- the one that is fastest
on *my* machine", but there are at least two such formats.  :(

Nowadays, almost all machines in modern use employ "IEEE floating-point",
which means they all agree about the formats of floating-point numbers,
but there are still the disagreements about endianness.

And these differences therefore still show up when writing unformatted
numerical data on one class of machine and then reading it back in on
another, unless you go to some trouble to avoid it.

(And g77 makes it harder than most compilers to avoid this trouble,
because it doesn't provide any natural way to say "open this file,
which was written on a big-endian machine" or some such thing.  Mostly
that's because it uses the libf2c library, which is distributed with
g77, but is not really part of the program g77 -- it comes from the
netlib repository.)

Note that simply taking four (or eight) bytes at a time from an unformatted
file and reversing the bytes in them is not always safe, because your
(or somebody's) program might have written different types of data to
it.  E.g. if it wrote a combination of REAL, INTEGER, DOUBLE PRECISION,
and CHARACTER data, then the CHARACTER data is not generally prone to
the endianness disagreements and thus must not be byte-swapped --
further, the DOUBLE PRECISION data presumably should be byte-swapped
eight (not four) bytes at a time.  It's even possible that the file comes
from an older system (like a VAX) and thus the REAL data must be
byte-swapped (and perhaps otherwise massaged) differently than the
INTEGER data.  (LOGICAL data, by the way, is usually treated exactly
the same as INTEGER.)

That's why it's *very* nice for the compiler to support the OPEN
statement specifying the precise format of the file in the sense
of "written on machine X by operating system Y running Fortran
compiler Z", so it can know exactly how to handle I/O to such a
file on a type-by-type basis, and do it at the right moment -- when
the program is READing or WRITEing variables of particular types.

(Of course, the program is asking for trouble if it READs to a variable
of one type and then, e.g. via EQUIVALENCE, treats it as another
type -- though, when compilers like g77 don't support automatic
conversion of the file as they should, this is a technique that is
often used to do it within the program instead, and it can work
pretty well in that context.)

So if you can't get the compiler to help you (which is the problem
with g77 and the other free Fortran "compiler", f2c), you have to
either modify your Fortran program to "cope" while actually reading
and/or writing the pertinent files (by doing the byte-swapping
itself), or, and this is much easier, by writing a program to convert
the files before and/or after they are used by the Fortran program
(so it can stay "pristine").

But a program to convert the files used read or written by another
Fortran program must "know" the format of the files, at least in the
sense of knowing the ordering and "lengths" of types of data written
to the file.  For some formats, this is easy (e.g. a file full of
nothing but DOUBLE PRECISION numbers), but for others, it gets harder
(you might have to read the entire Fortran program very carefully
to determine how it decides how much data of any given type to read or
write).

Hope this helps.

        tq vm, (burley)