This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io
- From: Steve Ellcey <sje at cup dot hp dot com>
- To: tobias dot schlueter at physik dot uni-muenchen dot de
- Cc: jblomqvi at cc dot hut dot fi, gcc-patches at gcc dot gnu dot org
- Date: Tue, 22 Feb 2005 09:02:32 -0800 (PST)
- Subject: Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io
> (adding Steve Ellcey to CC. Can you point us to some documentation of HP's
> record format?)
>
> That aside I would also be surprised if HP actually set the whole 32 bits to 1
> instead of simply setting the sign-bit and indicating that this is 64 bit
> record that way (i.e. if (reclen && 0x80000000 == 0) length = reclen; else
> length = (reclen && 0x7FFFFFFF) << 32 + the_32_bits_following_reclen;) , but
> without documentation or a HP compiler to try out, this is of course idle
> speculation, and it wouldn't solve your performance problem wither :-(
>
> - Tobi
The information I sent was from the Fortran Engineer who implemented it,
I don't know if there is any externally available documentation but I
will look around.
The description he gave was that they did check all the bits i.e. the
32 bit value had to be -1. I think the reasoning was to allow other
negative values to be used for other encodings if that was ever needed.
I think you may be under the impression that the header size is either
32 bits or 64 bits, but actually the header size is either 32 bits or 96
bits. If the first 32 bits == -1, then the full size is encoded in the
next 64 bits, with the initial 32 bits playing no part in the size
encoding but simply indicating that a 64 bit value follows the 32 bit
-1. The trailer is also 96 bits with the 64 bit size followed by the 32
bit -1 value.
Steve Ellcey
sje@cup.hp.com