From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,CTE_8BIT_MISMATCH,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII
X-Google-Thread: 103376,bd1a17edc1ccb2d6
X-Google-Attributes: gid103376,public
From: Vance Christiaanse <cintech@ix.netcom.com>
Subject: Re: Aggregate assignment problem with gnat under irix
Date: 1996/06/02
Message-ID: <31B15453.3911@ix.netcom.com>#1/1
X-Deja-AN: 158042823
references: <Pine.SGI.3.93.960531171236.29298A-100000@einstein.ph.utexas.edu>
to: ullar@einstein.ph.utexas.edu
content-type: text/plain; charset=iso-8859-1
organization: Cintech Consulting
x-netcom-date: Sun Jun 02  5:45:09 AM PDT 1996
mime-version: 1.0
reply-to: cintech@ix.netcom.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0b3 (Macintosh; I; PPC)
Date: 1996-06-02T05:45:09-07:00
List-Id: <comp.lang.ada>


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