Big array indexes (Was: Integer types for 128-bit addressing)

In article <419d0cc8$0$16487$4d4ebb8e@news.nl.uu.net>, Toon Moene wrote:
> It might bear repeating (it would be repetition on this news group) that
> as of mid-2000 I got regular complaints about g77's 0.5 Gb array size
> limit (note: this is about the size of a single array).
>
> In GCC 3.1 I managed to enlarge that to 2 Gb, now limited to the size a
> signed integer could address (mid 2001).  It was clear at that time that
> this would be a stopgap for at most another year.
>
> 2003 was the year of the cheap, comodity, 64 bit processor -
> unfortunately, that didn't change much for the I32LP64 community, the
> majority in computing land.

IIRC with the exception of MS, who is using IL32LLP64, the rest of the
world seems to be using LP64, right?

> What we need is ILP64, so that you can say:
>
> REAL A(1 000 000 000 000), B(1 000 000 000 000), C(1 000 000 000 000)
> READ *, A, B, C
> PRINT*, A*B+C
> END

Hm, IMHO ILP64 basically sounds like a kludge.

In this case, I think the savior and One True Way (TM) is F2003, which
I understand supports array indexes of non-default kind. Actually I
haven't found the spot in the draft standard that specifies this (it
just talks about some "scalar-int-expr"), but I have found out that
the array intrinsic functions have an extra optional argument
specifying the kind of the return value. Anyone care to confirm or
deny this?

Copies and followups to c.l.f.

--
Janne Blomqvist

>> What we need is ILP64, so that you can say: 

Note that you can do this today in most Fortran compilers by using a
compile-time -i8 switch, which leaves most 64-bit compilers in ILP64
mode.

>In this case, I think the savior and One True Way (TM) is F2003, which
>I understand supports array indexes of non-default kind.

I bet that you'll find that any 64-bit Fortran compiler which has a
default 32-bit integer has *some* means of using 64-bit array indexes,
e.g. by looking at the types the user is using as an index. This
leaves it up to the user to use a wide enough type, which is why
people seem to prefer to use -i8 to widen everything.

-- greg

"Janne Blomqvist" <foo@bar.invalid> wrote in message
news:slrncpshie.anl.foo@vipunen.hut.fi...

> In this case, I think the savior and One True Way (TM) is F2003, which
> I understand supports array indexes of non-default kind. Actually I
> haven't found the spot in the draft standard that specifies this (it
> just talks about some "scalar-int-expr"), but I have found out that
> the array intrinsic functions have an extra optional argument
> specifying the kind of the return value. Anyone care to confirm or
> deny this?

The bummer about 64-bit array indices (which is a little different
from 64-bit addresses) is that Fortran has these rules about
sequence association, like, for example: default integer storage
size must be the same as default real storage size.  An old Fortran
program that relies on this rule and uses default integers for array
indices will not admit of automatic porting to big array sizes, and
I believe that there are lots of programs like this.  These run-of-
the-mill program now become rather like the ones that poke instructions
into common and call from an address in common in that sense.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk wrote:

(snip)

> The bummer about 64-bit array indices (which is a little different
> from 64-bit addresses) is that Fortran has these rules about
> sequence association, like, for example: default integer storage
> size must be the same as default real storage size.  An old Fortran
> program that relies on this rule and uses default integers for array
> indices will not admit of automatic porting to big array sizes, and
> I believe that there are lots of programs like this.  These run-of-
> the-mill program now become rather like the ones that poke instructions
> into common and call from an address in common in that sense.

Well, a program relying on 32 bit integers to be big enough
as the size of other things increase will likely have other
problems.  It can always be fixed by using larger integers
when they are available.

Now, consider Java were subscripts are defined to be 32 bit
integers, even though Java has a 64 bit integer data type.
That will have to be changed someday.  Also, 32 bit integers
are big enough to address 32GB of eight byte reals, or
64GB of 16 byte complex variables, assuming more than 32 bit
addressing.

-- glen

-- glen

In article <419d0cc8$0$16487$4d4ebb8e@news.nl.uu.net>, Toon Moene wrote:

(snip)

>REAL A(1 000 000 000 000), B(1 000 000 000 000), C(1 000 000 000 000)
>READ *, A, B, C
>PRINT*, A*B+C
>END

Not a very good example.  First, this one requires the input to
contain 1000000000000 triplets of numbers, and if you only have
999999999999 you need a different program.  It also requires
all the A's followed by all the B's followed by all the C's.

Consider, then, that the input might consist of triplets, with
each triplet on one line.  The a loop containing:

READ *, A, B, C
PRINT *,A*B+C

would process it with no array limit at all.

-- glen

Janne Blomqvist <foo@bar.invalid> wrote in message news:<slrncpshie.anl.foo@
vipunen.hut.fi>...

> Hm, IMHO ILP64 basically sounds like a kludge.
>
> In this case, I think the savior and One True Way (TM) is F2003, which
> I understand supports array indexes of non-default kind.

The Fortran standards have allowed array bounds and subscript expressions
with nondefault kind type parameter values since there were kind type
parameter values (i.e., since Fortran 90).

> Actually I
> haven't found the spot in the draft standard that specifies this (it
> just talks about some "scalar-int-expr"), but I have found out that
> the array intrinsic functions have an extra optional argument
> specifying the kind of the return value.

The problem solved in the draft Fortran 2003 standard is that some
character functions and the array inquiry functions were required to
produce results which were integers of type default integer even
though the results might not be in the range of integers of type
default integer.

Note that the clause in the standard cited to allow an implementation
to restrict the bounds of an array or the length of a string is the
exclusion

This International Standard does not specify . . .

The size or complexity of a program and its data
that will exceed the capacity of any specific
computing system or the capability of a particular
processor.

Thus, the range of values of array bounds and subscripts may be any
subset of the representable integers.  In the days of 16-bit CPUs,
there were many Fortran implementations where integers were 32 bits
wide, but array bounds had to be in the range from -32,768 to 32,767.

Bob Corbett

In article <cb977dbc.0411200201.5481897b@posting.google.com>,
robert.corbett@sun.com (Robert Corbett) writes:

>     This International Standard does not specify . . .
>
>            The size or complexity of a program and its data
>            that will exceed the capacity of any specific
>            computing system or the capability of a particular
>            processor.

Right.  Thus, the following is a standard-conforming Fortran compiler,
implemented in DCL:

$ WRITE SYS$OUTPUT "%FOR-F-TOOCMPLX, program too complex for processor"

or, ported to unix:

echo "error: program too complex for processor"

One could complain about the quality of implementation, though.  :-)