This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran] patch for unformatted sequential writes
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: Bud Davis <bdavis at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Arnaud Desitter<arnaud dot desitter at ouce dot ox dot ac dot uk>, Andreas Jaeger <aj at suse dot de>, Toon Moene<toon at moene dot indiv dot nluug dot nl>
- Date: Thu, 17 Jun 2004 22:10:54 -0700
- Subject: Re: [gfortran] patch for unformatted sequential writes
- References: <1087527449.2921.17.camel@localhost.localdomain><87llilcye0.fsf@taltos.codesourcery.com><20040618043629.GA47540@troutmask.apl.washington.edu>
Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> On Thu, Jun 17, 2004 at 08:56:23PM -0700, Zack Weinberg wrote:
>> Oh ick. This is what they call a "please unbreak my program" toggle.
>> Why can't you use a variable-length encoding for the record size
>> (several such were posted the last time this came up) so that
>> everything just works?
>
> Do you have pointers to the previous posts? Bud is probably
> concerned with backwards compatibility with g77 and the future of
> 64-bit computing (amd64, ia64, etc) where 2 GB record lengths are
> prohibitive.
I am not having any luck finding the previous post, so let me just
describe the concept again (it's pretty simple).
Records between 0 and 0x7fff_ffff bytes long continue to have a single
32-bit record-size word fore and aft.
Records between 0x8000_0000 and 0x3ffff_ffff_ffff_ffff bytes have two
32-bit words: 1hhh hhhh 0lll llll fore, 0lll llll 1hhh hhhh aft.
This scheme extends indefinitely (hey, someday 2^62 bytes won't be
enough) - N-1 "1xxx xxxx" words, one "0xxx xxxx" word. And it should
not affect any existing code, since records <=2GB are still encoded
the same way. You have to use opposite word order fore and aft,
so that you always encounter the words with the high bit set first.
(Look up dwarf2's "[su]leb128" encoding - it's essentially the same
concept, applied on byte boundaries.)
zw