Re: Windows array allocation problem

James Van Buskirk <not_valid@xxxxxxxxxxx> wrote:

What happens when a bound gets over 32 bits

Its a hassle (unless default integer is 64 bits). Yes, you have to use a
64-bit integer kind (or, I suppose a 128-bit one, but that's rare) for
any value that exceeds the range of 32-bit integers, but it isn't quite
as bad as your question s indicate.

I suppose the bound given in the ALLOCATE statment has to
be a 64-bit variable of constant.

Well, sort of. No magic requirement here - just the "obvious". If a
32-bit integer can't represent the value being used, then you can't use
a 32-bit integer for that value. Note that this tautology does not
extend to any more esoteric requirement. It pretty much is just the
tautology. For example, just because one bound won't fit in 32 bits and
thus needs a larger kind, that doesn't say anything about the other
bounds.

Does this mean that any subsequent
array reference has to have a 64-bit index or array subscript triplet?

No. Absolutely not. Thats' important. It is perfectly fine to use a
32-bit integer... or heck, an 8-bit one if the particular value happens
to fit in one. There is not a requirement for kind agreement here. The
only requirement is the tautological one - that if a paticular value
won't fit in a particular kind of integer, then you can't use that kind
of integer for that value.

So if you have a variable that is being used as an index and can range
over the entire range of index values, you better use a 64-bit integer
fr that variable. But if the particular variable is only used for index
values that fit it 32-bits, the variable can stil be a 32-bit integer.

So this means that in many/most cases, yes, you will need index
variables to be 64-bit ones in practice. But that isn't a special
requirement.

Can an automatic array go over the top? Can an array expression do
this? Can an elemental procedure reference do this? What happens
when an assumed shape array gets passed a big actual argument?

Yes, all that works fine. That assumes, of course, that your compiler
ully supports large arrays. A compiler is free to have arbitrary size
limits on just about anything. The "obvious" case here is that a
compiler could have a 2GB (or other) limit on array sizes in general. I
suppose that a compiler could also do things like have a separate limit
on the size of arrays used in, say, elemental procedures. But that would
be a bit odd and would be a particular compiler issue rather than a
language restriction. If you run into something like that, then the
compiler isn't really fully supporting large arrays.

suppose that loops that use 32-bit indices would have problems,

Again, Only if the particular loop index variable exceeded the 32-bit
range. There is no extra rule.


but what about loopless array syntax?

No problem. Again, if you dont specifically have in your code a variable
(o constant) that gets a value that doesn't fit in its range, then there
isn't a problem. Sure things like loopless array syntax might be thought
of as having an implied loop variable "behind your back", but that
doesn't matter. The compiler is supposed to do it "right", which
presumably involves using large enough kinds for things that need it. If
the compiler doesn't get it right, bitch at the vendor. There could be
cases where you'll have to bitch. That wouldn't be shocking, as proper
support of large arrays does hit an awful lot of things.

The answer might concievably be that the vendor doesn't fully support
large arrays. But this isn't a language limitation. It is much like some
old compilers that, say, had array size limits much smaller than the one
directly implied by the size of default integers. For example, g77 has
(or at least had - I don't know whether it changed) a limit based on the
array size in bits fitting in a 32-bit integer. Yes, that is bits, not
bytes. That's just how the internals of the compiler worked; it isn't a
limit you'd guess from looking at anything in Fortran language in
general. There have been other older compilers with much smaller limits
than that.

What kind of problems have users
reported when trying to get big arrays working in a large, old program?

One that you overlooked is that a lot of pertinent intrinsics return
default integers. Thus for example, if you try to evaluate size(x),
where x has a size too large to be represented in a default integer,
then you'll have a problem.

F2003 (II think it was 2003; might have been 95, but I don't think so)
added an optional kind argument to all the intrinsics where this could
be an issue. You will also find this as an extension in some f95
compilers. (In fact, the compiler vendors who already had this were the
ones who proposed the feature for f2003). That's a bother, and
syntactically ugly as well, but it at least provides a workaround.

I think my last sentence above pretty much sumarizes the whole thing.
Using arrays whose sizes exceed the limits of default integers is a
bother and syntactically ugly, but it can be done (assuming, of coure,
that there is a sufficiently large integer supported at all, even if it
isn't the default integer kind).

Life is much simpler if the default integer kind is large enough for the
job. But it happens that there is a lot of old code that makes
nonstandard assumptions about default integers being exactly 32 bits.
Otherwise, upping the default integer kind would be the "obvious" thing
to do. No, there isn't a standard or portable way for the user to
specify the default integer kind.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: Idea for ECMA/C# Standard - compile time hash for performance
    ... I agree with you the chance of a compiler change is slim, ... and then delegating to the standard hash for fields accessed less frequently. ... or the array lookup which would require the ... > 64-bit architecture) for each enum value that doesn't map to anything. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Q: Checking the size of a non-allocated array?
    ... an actual argument is already invalid ... First note that you don't have an unallocated array in the subroutine. ... it is comparable to disassociated or undefined pointers. ... Obviously the compiler has ...
    (comp.lang.fortran)
  • Bounds checked arrays
    ... As everybody knows, the C language lacks ... When the state of this toggle is ON, the compiler ... Important is to know that the array updates ... We have just to allow him/her to specify what to do ...
    (comp.lang.c)
  • Re: Error handling library
    ... which lets the compiler catch out-of-range usage. ... and assuming that a higher int means "more dangerous error" ... with a comment warning that one is used as an index into the array ... languages while running (an array of languages, ...
    (comp.lang.c)
  • Re: switch() Statement Question
    ... specify the limits in a more robust manner, but a number of very bright ... I'm not experienced in the art of compiler design; ... This is actually a serious suggestion, not an April Fool's joke. ... int main ...
    (comp.lang.c)