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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d9f70618a1f87853
X-Google-Attributes: gid103376,public
X-Google-Thread: 115aec,707a256758168c49
X-Google-Attributes: gid115aec,public
X-Google-ArrivalTime: 2002-03-05 06:22:03 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!pipehawk.demon.co.uk!not-for-mail
From: john.mccabe@emrad.ns.com (John McCabe)
Newsgroups: comp.realtime,comp.lang.ada
Subject: Re: AdaMULTI/Ada 95 for Bare Board
Date: Tue, 05 Mar 2002 14:22:43 GMT
Organization: Emrad Ltd
Message-ID: <3c84cc9b.17546981@news.demon.co.uk>
References: <3C7CF687.15D36BBE@avionics.saab.se>
 <3C8356E5.28D0B600@icn.siemens.de> <3c83596e.9029553@news.demon.co.uk>
 <f2c4b613.0203050527.3381229f@posting.google.com>
NNTP-Posting-Host: pipehawk.demon.co.uk
X-NNTP-Posting-Host: pipehawk.demon.co.uk:158.152.226.81
X-Trace: news.demon.co.uk 1015338115 nnrp-07:7551 NO-IDENT
 pipehawk.demon.co.uk:158.152.226.81
X-Complaints-To: abuse@demon.net
X-Newsreader: Forte Free Agent 1.21/32.243
Xref: archiver1.google.com comp.realtime:4971 comp.lang.ada:20805
Date: 2002-03-05T14:22:43+00:00
List-Id: <comp.lang.ada>

On 5 Mar 2002 05:27:37 -0800, jim@ghs.com (Jim Gleason) wrote:

>I don't believe Green Hills claimed this.

You may not believe it, but this is exactly what I was told by Julian
Day (julian@ghs.com). He referred to RM95 4.3(5) as the justification.
Unfortunately all of this discussion was via email at my old work
address, but I am trying to get hold of the information and will post
it when/if it becomes available.

>Actually, the last two
>releases of the Green Hills compiler do NOT use a block of stack
>to temporarily hold the initial value before copying into the
>global variable.  The global variable (My_Large_Array) is initialized
>directly by the generated code.

Admittedly the problem I had was almost exactly 1 year ago, so you may
have released a different version since then. Unfortunately for us at
the time, it seemed that your excuse that the RM required this
behaviour meant nothing would be done to improve it!

Interestingly enough, the location of the temporary aggregate (as far
as I can remember) depended on the size: less than 1500 bytes and it
was created in global memory, over 1500 bytes and it was created on
the stack.

>I hope this clears this up.

Perhaps if you pointed me to the release notes that describe the
change....