From mboxrd@z Thu Jan 1 00:00:00 1970 From: Craig Burley To: egcs@cygnus.com Subject: Re: libf2c/configure.in change Date: Wed, 18 Feb 1998 14:54:00 -0000 Message-id: <199802181722.MAA19009@melange.gnu.org> References: <23456.887782573@hurl.cygnus.com> X-SW-Source: 1998-02/msg00893.html > > I think it shouldn't go in. Pity I didn't spot that definition and > > its import in the beginning. Breaking intra-platform compatibility > > can wait until we do inter-platform portability of unformatted > > files... >OK. We'll table this patch. Probably that is best. I've been so busy that it didn't occur to me, until this morning, just how important this issue is. (First, though, I do have to say that, because g77 is still officially in *beta testing*, it is not so crucial as it would be in a product that isn't. That is, we need to work this, and any similar, issues out once and for all during this beta-test period.) Basically, the problem is that libf2c, like pretty much any Fortran run-time library, makes what amounts to its "own" decision as to what the format of an unformatted file should be. (In Fortran, an unformatted file is kind of like a "binary" file in C, in that data is read or written to it at a "raw" level. However, this level is somewhat higher-level than in C. In C, one simply write()'s, or whatever, an array or struct or whatever. In Fortran, statements like "WRITE (10) A, B" accomplish that -- the difference between that statement and "WRITE (9, '(F10.5)') A, B" is that the latter specifies that the arrays are to be written using formatted I/O, which is like C's `printf("%f10.5",...);'. The program that runs in an unformatted file must match the data types, array sizes, and lengths, basically, but not explicit layout that Fortran doesn't really have anyway, a la C's alignment stuff.) Because Fortran provides unformatted I/O as a *language* feature, it's more important for a Fortran vendor (like g77) to really understand and explain just what an unformatted file *is* in that system. Choices include (but probably are not limited to, even in practice): 1. A file that is assumed to be read and written using unformatted I/O *only* in programs compiled with the exact same version of the compiler on the exact same kind of system (OS and CPU). That is, the file is binary-compatible with other files written by code compiled by the exact same compiler, but basically no other guarantees are made. Programmers wanting a more "universal" format must use formatted I/O or write code to do the binary encoding directly using low-level facilities (e.g. libU77). 2. Same as #1, but the vendor promises to make the file "work" across a range of versions of the compiler on that system (e.g. "this compiler writes unformatted files that this and all future versions of this compiler will read"). 3. Same as #1, but the vendor promises to make the file "work" across a range of systems the compiler and version supports. (Nice when sharing files across NFS, for example.) 4. Best of #1 plus #2. 5. A file that is binary-compatible with a range of *other* compilers that support that system. (E.g. "this compiler employs an unformatted-file format that is binary-compatible with Smegma f77 v99.88".) 6. A file that is binary-compatible with some industry-wide standard. As you might guess, some of the promises conflict with others as a *default*, but they're basically all useful in different situations. And, the more that is promised, generally speaking, the less performance can be delivered -- which is why some promises are not made the *default*, because, also generally speaking, Fortran programmers use unformatted I/O when they *need* performance. For example, defaulting to some industry-wide standard, or to a single format that, say, *all* systems g77 runs on (now or in the future), has the obvious advantages, but at least one big disadvantage, in that, for certain systems, I/O would go *much* slower in some cases because of endian and other differences between the CPU architecture and the file format. Since it would *really* be nice for g77 to at least offer all of the above as *options*, meaning options on the OPEN statement (this is apparently how other vendors do it), I think this whole issue basically requires "punting" to the long-hoped-for new run-time-library (which we cleverly code-name "libg77" ;-). And, picking the *default* choice should be simply a matter of just that, once all the options are available. Whether we'll *ever* want to change the default from "whatever g77+libf2c delivered in the past", so as to give users no hard work to cope with reading in data written, in the past, by g77 releases, I can't say. The fact that libf2c has already, apparently, made an incompatible change doesn't necessarily mean we have to. But if that change means 64-bit systems like Alphas get 64-bit capacity in record length, and we don't accept it, then, while we're thus ensuring existing files get read in "naturally", we aren't defaulting to a model whereby users of g77 on Alphas get more than an artificial 32-bit limit on their record lengths. I hope I've accurately laid out most of the issues above. Mostly, in summary, I've saying "there's a lot to think about here, and we aren't really close yet to having enough choices in the matter". I *think* that implies that, indeed, it's best to not "rock the boat" in any way until we know more about what we're doing, and can elucidate those plans better. So indeed it seems best to not modify g77, even in the form of netlib-sanctioned libf2c patches, to introduce changes in the format of unformatted files on any systems that have been supported by g77 in the past, until we are in a better position to offer real choices to our users. tq vm, (burley)