Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!nott-cs!anw
From: anw@nott-cs.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Dynamic array dimensioning
Message-ID: <604@tuck.nott-cs.UUCP>
Date: 9 Jan 89 15:34:02 GMT
References: <117400002@uxa.cso.uiuc.edu> <6847@june.cs.washington.edu>
Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker)
Organization: Department of Mathematics, The University, NOTTINGHAM, NG7 2RD, UK.
Lines: 43

In article <6847@june.cs.washington.edu> pardo@cs.washington.edu (David
Keppel) writes:
> [other languages], such as Ada, Algol, Simula, and PL/1 have
>array size bound and procedure entry time.

	Minor nit:  in Algol, new arrays can arise (more-or-less) anywhere,
and their sizes cannot, in general, be bound until the relevant code is
actually executed.

>Dynamic sizing is more expensive than static dimensioning for at least
>the following reasons:
>
>* The stack frame doesn't have a fixed size.  Thus you need two
>  registers dedicated to the call frame. [...]

	Yes.  Conventionally, these will be the "local base" and the "stack
pointer".  Obviously, with fixed-size frames, the SP can double as the LB;
however, this means that temporary variables must share the same base as
ordinary variables, perhaps moving some of them outside the convenient range
of "offsets", that (in some environments) interrupts may be harder to handle,
variadic procedures may be harder to handle, etc.  Coping with this is
certainly possible, but imposes extra rules on the storage layout that may
or may not increase code size or reduce speed.

>* Fewer array indexing optimizations are possible.

	True:  for example, initial array accesses must be channelled
through a dope vector instead of directly to a known location.  On the
other hand, the programmer is more likely to write code that is amenable
to optimisation:  eg, copy the whole of an array to another array, instead
of just the top left-hand corner.

Dynamic sizing is cheaper than static dimensioning for at least
the following reasons:

* Arrays are just the right size, instead of as big as they might possibly
  need to be, some day, some time.

* User convenience.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk