Van Snyder wrote:
>
> Dick Hendrickson wrote:
>
> > I don't remember for sure, but I think one reason was to avoid having
> > more than seven subscripts in an array reference by using several
> > components with several dimensions each. There didn't seem to be
> > a clean way to resolve this. Limiting the total to only seven
> > seems artificial (as do many other things) and allowing more than
> > 7 is inconsistent with normal non-component-arrays. Allowing more
> > than 7 for normal arrays is likely to be non-portable. Picking a
> > number (like 15) is portable, saying "processor dependent" isn't.
>
> Application of the "a number is portable; saying `processor dependent'
> isn't" rule is sporadic.
Sure, like most "rules" it's really a guideline. But in this case, I
think it's a reasonable one. I could go along with 15 or some other
small number, but not unspecified (at least not wihtout hearing more).
I think we need to balance regularity with likely ease of use. If
compiler A lets me nest DO loops 20 deep and compiler B lets me nest
them only 15 deep, I can port from A to B merely by replacing 5 DO
loops with IF--GOTO combinations. And, I claim, this replacement
will not affect the performance (or readability!) of a code with
DO loops nested 20 deep. And what you will observe is that users
who plan ahead for porting (if there are any ;-} ) will limit
their coding to use the portable maximum.
Similarly, the MAX/MIN functions accept any number of arguments,
in theory. In practice, the compilers I know about limit the
number to 20 or so, but it's easy to code around this limit
at a (small IMO) cost in clarity.
If I need an array that is bigger than the compiler can address (or
chooses to address because of hardware complexity) then there's no
hope, I just need to buy a bigger machine/compiler.
To me, array rank is more like array size than it is like DO loop
depth. There is no practical way to port a significant code
by reducing array ranks and preserve readability and style. Since
there is going to be a practical maximum anyhow, I think it's a
better choice to pick a reasonable size. Vendors can extend their
compiler if they feel it is important. Also, I don't think there
has been a general outcry for a larger limit. Particularily
one supported by "real" examples from different fields. That's
a pretty opinionated statement and it's also circular.
Since the feature isn't there, people don't plan on using it,
so they don't complain about it not being there.
Personally, I'm comfortable with limits on things that, to me,
appear hard to port around. Things like array ranks or variable
name size.
Dick Hendrickson
>
>There are numerous places where the standard
> could have applied the rule, for example in DO nesting depth, but
> didn't. Instead, we have, in Subclause 1.4, on page 1:
>
> "The standard does not specify
> ...
> (3) 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."
>
> My compiler manuals list limits for things like DO nesting depth, number
> of dummy arguments, number of files open concurrently, .... The limits
> are so ridiculously large that I've never had a portability problem
> caused by excedding them in one instance and not in another.
>
> So the question now becomes: Why does the standard put a particular
> limit in this case instead of appealing to this rule?
>
> One of my compilers puts a limit on array size, such that the magnitude
> of the addressing offset (presumably in bytes), or any intermediate
> result in the addressing offset calculation, shall not exceed 2^30.
> The base-2 logarithm of this limit, viz. 30, would be a reasonable
> "processor dependent" limit. The limit of seven is an anachronistic
> artifact arising from the IBM 7094 architecture: The 7094 had seven
> index registers.
>
> It's time for this hard limit to be replaced by the general caveat on
> page 1.
>
> --
> What fraction of Americans believe | Van Snyder
> Wrestling is real and NASA is fake? | [log in to unmask]
> Any alleged opinions are my own and have not been approved or disapproved
> by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.
|