Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ucscc.ucsc.edu!gorn!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.lang.pascal
Subject: Re: Larger arrays.
Keywords: It's not the hardware - it's not the language
Message-ID: <18.filbo@gorn.santa-cruz.ca.us>
Date: 2 Sep 89 15:55:22 GMT
References: <362@e-street.Morgan.COM>
Organization: R Pentomino
Lines: 55
X-Claimer: I >am< R Pentomino!

In article <362@e-street.Morgan.COM> Andrew P. Mullhaupt writes:
[Long, reasonable argument for "huge" arrays in PC Pascals deleted]
>1.     They don't think enough of us care to make it worthwhile, that is:
>   They are afraid that the first one to put in sensible arrays will lose
>   out on the specsmanship (benchmarketing) issue: An unrealistic benchmark,
>   like finding the first thousand primes a hundred times, might very well
>   point out the cost of correct implementation of arrays. In the Pascal
>   market, it is a judgement call which side (much bigger/slightly faster)
>   of the issue the market share falls in. 
>
>2.     They are worried that some people will be unhappy with them if
>   existing source code (which may have already been carefully tweaked to
>   go fast) slows down when recompiled under a new version, or worse yet
>   doesn't work due to overactive bit-picking efficiency tricks
>   programmers may have unwisely used.
>
>Finally: I would settle for a compiler directive that switched between
>the little and big styles, and the restriction that an entire program
>(all its units, etc.) be compiled with one setting consistently throughout.

I don't know about MicroSoft, but I'm fairly familiar with the "philosophy"
behind Turbo Pascal.  (I quote "philosophy" because I don't think there >is<
a formally thought-out philosophy behind it).  First, I'd be fairly surprised
if Borland came out with huge-array support, except on '386 or other
processors with large linear address space.  But if they did, I'd be quite
astonished if it worked the way you suggest.  I would expect the compiler to
automatically determine, at compile time, whether an array declaration was
less or greater than 64K, and generate the appropriate code for references to
>that array< based on its size.  Since Turbo doesn't have any sort of dynamic
arrays (ignoring trickery with the heap, which as always would be the
programmer's responsibility), there's no question at compile time of the size
of a particular variable.  Turbo already knows how to deal with different
types of variables under the same syntax (witness:

  Var
    F: File Of Integer;
    T: Text;
    I: Integer;
  ...
    Write(F,I);
    Write(T,I);
  ...

Entirely different code is generated).

The only disadvantage to this approach is that support routines for
calculating both kinds of array offset would be pulled into a program that
used both types of array.  But this code would be very small, and incurred
>only< when both were used, so I see no problem.  >Bela<

>Andrew Mullhaupt

Bela Lubkin     * *   filbo@gorn.santa-cruz.ca.us   CIS: 73047,1112
     @        * *     ...ucbvax!ucscc!gorn!filbo    ^^^  REALLY slow [months]
R Pentomino     *     Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945