Aggregate assignment problem with gnat under irix

Aggregate assignment problem with gnat under irix

[Ullar Kask]

Hello,

  I am doing numerical simulations using Ada and encoutered a problem with
aggregate assignment. The same type of statement, viz.,

  A.all := (others => (others => 0.0));

where A.all is an NxN array (declared as unconstrained), works great in simple
procedures but fails in a task body. I don't understand what may be
the reason.

To be more specific, consider the following piece of code (compiles cleanly
with irix5.3 binary distribution of gnat 3.04 under irix5.2):

--------------------------------------------------------------------------------

with Ada.Text_IO, Interfaces.Fortran, Ada.Exceptions;
use  Ada.Text_IO;

procedure Aggr_Tst is

  subtype Real is Interfaces.Fortran.Real;

  type Matrix_Type is array (Integer range <>, Integer range <>) of Real;
  pragma Convention( Fortran, Matrix_Type);

  type Matrix_Type_Access is access Matrix_Type;

  type Grid_Type is (COARSE, MEDIUM, FINE);


  Lhs : array (Grid_Type) of Matrix_Type_Access;


  Grid_Length : array (Grid_Type) of Positive;

  Grid        : Grid_Type;


  task Some_Task is
    entry Entry_Point( G : in Grid_Type);
  end Some_Task;


  task body Some_Task is

    Grid : Grid_Type;

  begin

    accept Entry_Point( G : in Grid_Type) do
      Grid := G;
    end Entry_Point;

    --
    -- Some work is being done here with Lhs(Grid).all
    -- After that, try to initialize it again:
    begin

      -- The following statement raises STORAGE_ERROR:
      Lhs(Grid).all := (others => (others => 0.0));

      -- So does this:
--      Lhs(Grid).all := (Lhs(Grid).all'RANGE(1) =>
--                        (Lhs(Grid).all'RANGE(2) => 0.0));

      -- And this:
--      Lhs(Grid).all := (-Grid_Length(Grid) .. Grid_Length(Grid) =>
--                        (-Grid_Length(Grid) .. Grid_Length(Grid) => 0.0));

      -- Only the following double-loop does the job:
--      for I in Lhs(Grid).all'RANGE(1) loop
--        for J in Lhs(Grid).all'RANGE(2) loop
--          Lhs(Grid)(I,J) := 0.0;
--        end loop;
--      end loop;

    exception
      when O: others =>
        Put_Line( "***Lhs initialization failed!***  Exception " &
                  Ada.Exceptions.Exception_Name(O) & " raised in task body.");
        raise;
    end;

    Put_Line( "Lhs initialized again in task body.");

  end Some_Task;


begin

  -- Some values assigned to Grid and Grid_Length(Grid):
  Grid := COARSE;
  Grid_Length(Grid) := 100;

  -- Allocate matrix:
  Lhs(Grid) := new Matrix_Type(-Grid_Length(Grid) .. Grid_Length(Grid),
                               -Grid_Length(Grid) .. Grid_Length(Grid));

  -- Initialize matrix:
  begin

    Lhs(Grid).all := (others => (others => 0.0));   -- This works fine

  exception                                         -- No exceptions raised here
    when Q: others =>
      Put_Line( "***Lhs initialization failed!***  Exception " &
                Ada.Exceptions.Exception_Name(Q) & " raised in main procedure");
      raise;
  end;

  Put_Line( "Lhs initialized in main procedure.");


  -- Do some work with the matrix:
  Some_Task.Entry_Point( Grid);

end Aggr_Tst;
------------------------------END OF CODE SAMPLE--------------------------------


Has the STORAGE_ERROR raised in the task body (under irix) something to do
with the size of the task stack? How it happens that such an aggregate
assignment is possible outside a task body but fails inside?

Any comments on the issue are appreciated!

Thanks a lot!


================================================================================
�llar Kask
Center for Relativity, University of Texas, Austin
email: ullar@einstein.ph.utexas.edu
ph. (512) 471-5905
http://wwwrel.ph.utexas.edu/Members/ullar/

Re: Aggregate assignment problem with gnat under irix

[David C. Hoos, Sr.]

Ullar Kask <ullar@einstein.ph.utexas.edu> wrote:

>Hello,

>  I am doing numerical simulations using Ada and encoutered a problem with
>aggregate assignment. The same type of statement, viz.,
.
.
.

>Has the STORAGE_ERROR raised in the task body (under irix) something to do
>with the size of the task stack? How it happens that such an aggregate
>assignment is possible outside a task body but fails inside?

Yes, I believe it does.  I don't know what the default task stack size
is for gnat, but on other compilers I have used it is as low as 10Kb.

The solution is to use the pragma Storage_Size (<integer-expression>)
inside the task declaration.

David C. Hoos, Sr.
http://www.ada95.com
http://www.dbhwww.com

Re: Aggregate assignment problem with gnat under irix

[Vance Christiaanse]

Ullar Kask wrote:

> Hello,
> 
>   I am doing numerical simulations using Ada and encoutered a problem with
> aggregate assignment. The same type of statement, viz.,
> 
>   A.all := (others => (others => 0.0));
> 
> where A.all is an NxN array (declared as unconstrained), works great in simple
> procedures but fails in a task body. I don't understand what may be
> the reason.

[ ... code sample deleted ... ]
 
> Has the STORAGE_ERROR raised in the task body (under irix) something to do
> with the size of the task stack? How it happens that such an aggregate
> assignment is possible outside a task body but fails inside?
> 
> Any comments on the issue are appreciated!
> 
> Thanks a lot!
> 
> ================================================================================
> �llar Kask
> Center for Relativity, University of Texas, Austin
> email: ullar@einstein.ph.utexas.edu
> ph. (512) 471-5905
> http://wwwrel.ph.utexas.edu/Members/ullar/

Your task-stack-size theory is correct.  If I ran your code in the tasking
environment I am most familiar with (Verdix Ada on 680X0), it would behave as
you've described for the reason you suspect.

Heap memory is allocated in chunks starting from the low-address end of free
memory and the main procedure stack starts at the high-address end.  Each task
stack is allocated out of the heap with a fixed size.  (The default in the
Verdix environment is about 10 Kbytes.)  But the main-procedure stack size is
all of free memory minus whatever has been taken out of the heap.

Your array contains 40,401 reals (plus dope information).  An aggregate
assignment requires that much stack space (temporarily) so the entire
aggregate can first be built in a scratch area before the actual assignment
to the destination is made.  (That way, if an exception occurs during
evaluation of the aggregate, the destination won't be left in a partially-
updated state.)

It looks as though the default task stack size in your environment is not
large enough to allow 40+ Kbytes of temporary storage but your main procedure
stack is large enough.

Vance

Vance Christiaanse
Cintech Consulting
Syracuse, NY
cintech@ix.netcom.com

Re: Aggregate assignment problem with gnat under irix

[Vance Christiaanse]

David C. Hoos, Sr. wrote (regarding a question from Ullar Kask):

> The solution is to use the pragma Storage_Size (<integer-expression>)
> inside the task declaration.

This may be the most elegant solution if you have lots of memory, but
you have to ask yourself whether it's worth dedicating 40 Kbytes to
hold zeros just so you can do one aggregate assignment.

_If_ memory is a scarce resource, the loops in Ullar Kask's original
code are a better solution.  The nested loops _may_ actually execute
faster, as an extra bonus.

Vance

Vance Christiaanse
Cintech Consulting
Syracuse, NY
cintech@ix.netcom.com

Re: Aggregate assignment problem with gnat under irix

[Keith Thompson]

In <31B15453.3911@ix.netcom.com> Vance Christiaanse <cintech@ix.netcom.com> writes:
> Ullar Kask wrote:
> >   I am doing numerical simulations using Ada and encoutered a problem with
> > aggregate assignment. The same type of statement, viz.,
> > 
> >   A.all := (others => (others => 0.0));
> > 
> > where A.all is an NxN array (declared as unconstrained), works great
> > in simple procedures but fails in a task body. I don't understand
> > what may be the reason.
[...]
> Your array contains 40,401 reals (plus dope information).  An aggregate
> assignment requires that much stack space (temporarily) so the entire
> aggregate can first be built in a scratch area before the actual assignment
> to the destination is made.  (That way, if an exception occurs during
> evaluation of the aggregate, the destination won't be left in a partially-
> updated state.)

Note that, in this particular case, evaluation of the aggregate cannot
raise an exception, so the temporary scratch area is not strictly
necessary.  The compiler could generate code to build the aggregate value
directly in the target of the assignment, after first doing a few required
checks (A /= null, for example).  Apparently GNAT does not (yet?) perform
this optimization -- not surprising, since the GNAT folks are still
concentrating on implementing the language and generating correct code.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
This sig uses the word "Exon" in violation of the Communications Decency Act.