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

[Adam Beneschan <adam@irvine.com>]

On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh
+bauh...@maps.futureapps.de> wrote:
> On Tue, 2007-10-30 at 02:47 -0700, Ludovic Brenta wrote:
> > Pascal Obry wrote:
> > > ME a crit :
>
> > > > What is the largest array (in storage units) that you can declare in Gnat
> > > > 2005 for the PC?
> > In short, the answer is: "it depends" :)
>
> Indeed, it depends;-) I thought that declaring an array *type*
> of enormous size is not a problem, since there is no object
> yet. It isn't a problem. So maybe using portions of the array might
> work (when the program is not actually using physical memory.)
> I get unexpected results,though, but they are consistently produced
> by two unrelated compilers targeting two (seemingly unrelated)
> machines!
>
> This is the only hint I have found in the assembly
> listing; '?' is $63, '!' is $33, this is for the lines
> assigning Fst and Lst in the second declare block below.
> Notice the -1 for the stack offset
>
>         movl    $0, %eax
>         movb    $33, -1(%ebp,%eax)    -- ( Fst := '!' )
>         movl    $0, %eax
>         movb    $63, -1(%ebp,%eax)    -- ( Lst := '?' )
>
> Is there a bug in the following program or maybe I'm just dense?

EAX is a 32-bit register, right?  (We weren't told what processor
Georg is running on---but the above looks like Pentium/80x86 to me.)
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.  The same would happen when it
reads from the array to print the result, so that's why you're
seeing ?? as output.

But you're declaring an array object X of size 255*(2**40), which
can't be handled on a machine with a 32-bit address space; so I'm
confused about why you'd expect the program to work, unless one of the
two machines you're referring to has a 64-bit address space and the
compiler is generating incorrect code anyway.  Or unless I'm totally
confused as to what you're asking.  Anyway, however, this looks like a
compiler bug---if it is unable to generate correct code because of the
array size, it should reject the program.

                      -- Adam


>
> with Ada.Text_IO;
>
> procedure stk is
>
>         use Ada;
>
>         type Big_Index is range 0 .. 2**50;
>
>         type A is array (Big_Index range <>) of Character;
>
> begin
>
>         -- output is "!?"
>         declare
>                 X: A (Big_Index range 2**40 .. 2**40 + 10_000);
>                 Fst: Character renames X(X'First);
>                 Lst: Character renames X(X'Last);
>         begin
>                 Fst := '!';
>                 Lst := '?';
>
>                 Text_IO.Put(Fst);
>                 Text_IO.Put(Lst);
>                 Text_IO.New_Line;
>         end;
>
>         -- output is "??"
>         declare
>                 X: A (Big_Index range 2**40 .. 2**48);
>                 Fst: Character renames X(X'First);
>                 Lst: Character renames X(X'Last);
>         begin
>                 Fst := '!';
>                 Lst := '?';
>                 pragma assert(Fst = '!');
>
>                 Text_IO.Put(Fst);
>                 Text_IO.Put(Lst);
>                 Text_IO.New_Line;
>         end;
> end stk;