traymund@uiuc.edu (Tim Raymund) (03/22/91)
Is there a f77 compiler option to swap byte order on i/o? I ran
the same program on a DECstation 5000 and an HP 9000/835 (see program
at the end) and the resulting files look like:
DECstation 5000> od -h float.data
0000000 0028 0000 0000 3f80 0000 4000 0000 4040
0000020 0000 4080 0000 40a0 0000 40c0 0000 40e0
0000040 0000 4100 0000 4110 0000 4120 0028 0000
0000060
HP 9000/835> od -h float.data
0000000 0000 2800 803f 0000 0040 0000 4040 0000
0000020 8040 0000 a040 0000 c040 0000 e040 0000
0000040 0041 0000 1041 0000 2041 0000 0000 2800
0000060
We like to use binary file i/o as in the program, and it would
be handy if a f77 compiler option could be set to make the
files identical across systems.
Thanks for any help!
tim raymund
traymund@uiwpl.ece.uiuc.edu
program gen
integer n
parameter (n = 10)
real numb(n)
integer i
do i = 1,n
numb(i) = float(i)
end do
open (21, file='float.data',access='SEQUENTIAL',
$ form='UNFORMATTED',status='UNKNOWN')
rewind (21)
write (21) numb
close (21)
stop
end
--
Tim Raymund
Wave Propagation Lab, Department of Electrical and Computer Engineering,
University of Illinois, 1406 W. Green St., Urbana, IL 61801-2991 USA
Internet: t-raymund@uiuc.edu Phone: 217/333-2931 FAX: 217/244-5624tihor@acf3.NYU.EDU (Stephen Tihor) (03/22/91)
dd can swap bytes. Unfortunately the things that make binary i/o good argue against tricks liek byteswapping. Still if HP supports it you can make a case that DEc should to for competitive reasons. I bet they don't though.
jg@crl.dec.com (Jim Gettys) (03/22/91)
In article <12660002@acf3.NYU.EDU> tihor@acf3.NYU.EDU (Stephen Tihor) writes: >dd can swap bytes. Unfortunately the things that make binary i/o good argue >against tricks liek byteswapping. Still if HP supports it you can make a >case that DEc should to for competitive reasons. I bet they don't though. You'd lose that bet, with the new release of DEC Fortran on the RISC machines. When you open a file (or by setting an environment variable) you can specify that bytes should be appropriately swapped. This works for well formed binary I/O (i.e. you'd better not be playing evil tricks equivalencing stuff to what you are reading in). This compiler has gone to the software distribution center, and should start appearing in customers hands in the not too distant future. Note that it also helps with converting to and from VAX floating point format as well. To quote from the release notes of DEC Fortran for Ultrix RISC Systems Version 3.0: 1.7.1 Support for Big/Little Endian and VAX Floating Point Data DEC Fortran contains features that allow Fortran programs to read unformatted binary files that contain either data in big-endian byte order or floating point data in VAX format. When the user specifies that a file has either of these attributes, all unformatted READs and WRITEs will process the elements of the I/O list and perform the necessary conversion. These tools provided by DEC Fortran for handling big endian and VAX floating point binary data in files are only a partial solution because it depends on the application being "data type clean", ie, the data in the file must be processed by an I/O list that uses the data types of the data in the file. For example, if lots of data is EQUIVALENCEd to an INTEGER array and then that array is written out, the data types of the actual data are not correctly represented by the data types of the I/O list elements (in this case, INTEGER) and correct conversion will not take place. There are several ways to specify that a file should have conversion attributes: o a compiler option spelled "-assume big_endian" tells DEC Fortran that all files opened for unformatted READs and WRITEs in the program being compiled contain big endian binary data. All the user has to do is recompile his application (or just the routines that touch the big endian files) with "-assume big_endian", and the READs and WRITEs will convert the data from big to little endian and back. 1-22 DEC Fortran for ULTRIX RISC Systems Release Notes ^L o "-assume vaxd" means that the file contains little endian data in VAX floating point format and that double precision is in VAX D format. o "-assume vaxg" means that the file contains little endian data in VAX floating point format and that double precision is in VAX G format. o An environment variable, named FORT_CONVERTn, associated with Fortran I/O unit number "n", contains the conversion attributes for the file associated with that unit at run-time. The settings would look like - setenv FORT_CONVERTn "BIG_ENDIAN" - setenv FORT_CONVERTn "VAXD" - setenv FORT_CONVERTn "VAXG" to set the attribute for the file associated with unit = n. DEC Fortran already uses the environment variable FORTn to be the file spec for the file opened on unit = n. o For those who are willing to modify their source code, there is a new keyword on the OPEN statement: OPEN (... CONVERT = 'BIG_ENDIAN', ...) OPEN (... CONVERT = 'VAXD', ...) OPEN (... CONVERT = 'VAXG', ...) that specifies the attributes for the file. The INQUIRE statement also recognizes the CONVERT keyword and returns a character string of the conversion attribute set for the file. The default is 'LITTLE_ENDIAN' which implies IEEE floating point. -- Digital Equipment Corporation Cambridge Research Laboratory
peterson@fman.enet.dec.com (Bob Peterson) (03/23/91)
In article <traymund.669594979@uiwpl.ece.uiuc.edu>, traymund@uiuc.edu (Tim Raymund) writes: >Is there a f77 compiler option to swap byte order on i/o? I ran >the same program on a DECstation 5000 and an HP 9000/835 (see program >at the end) and the resulting files look like: ... >We like to use binary file i/o as in the program, and it would >be handy if a f77 compiler option could be set to make the >files identical across systems. Yes. The DEC Fortran V3.0 compiler might help. It is capable of byte swapping and VAX<->IEEE conversion on binary I/O. The drawbacks of this are that FORTRAN programmers sometimes equivalance a lot of data in COMMON to a single integer vector, and then do I/O with the vector. The conversions then may fail. The experimental support allows you three options to control this: a per-unit environment variable, a compiler option affecting all units, and a new OPEN statement keyword, CONVERT. Details on request. We haven't had enough experience with this to catch all the gotchas. One gotcha: the binary data may be converted, but the binary record formats have to be the same as well. We think we match formats pretty well, but like I said, we're in learn mode. \bob