Re: Largest size array in Gnat 2005 for the PC?

[Adam Beneschan <adam@irvine.com>]

On Oct 30, 2:40 pm, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:
> On Tue, 2007-10-30 at 13:24 -0700, Adam Beneschan wrote:
> > On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh
> > > Is there a bug in the following program or maybe I'm just dense?
>
> > EAX is a 32-bit register, right?
>
> Yes, i686 Linux in this case. When I ask the compiler for
> 64bit code, then I see occurrences of $280375465082880,
> which is 2**48 - 2**40.
>
> > So to assign into the first element of Fst, the offset from the
> > beginning of the array is 0; to assign into the last element, the
> > offset will be (2**48 - 2**40) which is 255 * 2**40, which is way too
> > big to fit into a 32-bit register, so apparently the compiler is
> > truncating to 0 before setting EAX.
>
> Ah, yes. Could exceeding size have produced the -1 in
>  -1(%ebp,%eax), %eax
> too? It is
>  -10002(%ebp,%eax), %eax
> for the "normal size" array of 10_000 elements?

Your array is 10_001 elements, actually.  I haven't studied code
produced by GNAT very much, but -1 just looks like the starting point
for where things are allocated (downward) from the current stack frame
pointer (EBP); exceeding size would have produced -1 in that if the
compiler truncates the array size and thinks the size is 0, then the
resulting offset would have been -1.  I'll bet that if you declared an
array of one byte, you would have seen -2(%ebp,%eax); if it were two
bytes, -3(%ebp,%eax), and so on.  I'm just speculating, though... I
haven't tried this myself.

                       -- Adam