Re: AdaMULTI/Ada 95 for Bare Board

Re: AdaMULTI/Ada 95 for Bare Board

[Alfred Hilscher]

Try to ask this question on news:comp.lang.ada maybe you will get more
response there.

Mikael Lundqvist wrote:
> 
> Hi!
> 
> We are about to start using Green Hills AdaMULTI/Ada 95 for Bare Board
> (PowerPC). Having used ApexAda before with mixed results we are hoping
> for an improvement. Does anybody have experience with AdaMULTI/Ada 95
> for Bare Board to share?
> 
> Regards,
> Mikael

Re: AdaMULTI/Ada 95 for Bare Board

[John McCabe]

On Mon, 04 Mar 2002 12:13:41 +0100, Alfred Hilscher
<Alfred.Hilscher@icn.siemens.de> wrote:

>> We are about to start using Green Hills AdaMULTI/Ada 95 for Bare Board
>> (PowerPC). Having used ApexAda before with mixed results we are hoping
>> for an improvement. Does anybody have experience with AdaMULTI/Ada 95
>> for Bare Board to share?

Watch out for allocation of huge stack areas for aggregate assignments
to arrays...

e.g.:

type Large_Array is array (1..100, 1..10, 1..1000) of integer;
My_Large_Array : Large_Array;

procedure Initialise
begin
    My_Large_Array = (others => 0, others => 0, others => 0);
end Initialise;


will attempt to allocate a 4MByte or so block of stack to create an
aggregate before copying it to the global variable (My_Large_Array).
Green Hills claim it is *required* by the RM, but certain people who
were involved in writing the manual disagree!

Re: AdaMULTI/Ada 95 for Bare Board

[Martin Dowie]

> Watch out for allocation of huge stack areas for aggregate assignments
> to arrays...
[snip]
> will attempt to allocate a 4MByte or so block of stack to create an
> aggregate before copying it to the global variable (My_Large_Array).
> Green Hills claim it is *required* by the RM, but certain people who
> were involved in writing the manual disagree!

To be fair to GHS, their compiler isn't the only one that will do this...
;-)

Re: AdaMULTI/Ada 95 for Bare Board

[Ted Dennison]

john.mccabe@emrad.ns.com (John McCabe) wrote in message news:<3c83596e.9029553@news.demon.co.uk>...
> Watch out for allocation of huge stack areas for aggregate assignments
> to arrays...
>     My_Large_Array = (others => 0, others => 0, others => 0);
> 
> will attempt to allocate a 4MByte or so block of stack to create an
> aggregate before copying it to the global variable (My_Large_Array).
> Green Hills claim it is *required* by the RM, but certain people who
> were involved in writing the manual disagree!

(assuming you meant ":=")

I believe this would be required in certian situations if the source
for the data came from overlapping parts of the same object. Perhaps
the answer you got was vendor shorthand for "there are some situations
where this would be required, and we don't want to do the work
required to recognise those situations and do something different."
:-)

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: AdaMULTI/Ada 95 for Bare Board

[John McCabe]

On 4 Mar 2002 12:16:20 -0800, dennison@telepath.com (Ted Dennison)
wrote:

>john.mccabe@emrad.ns.com (John McCabe) wrote in message news:<3c83596e.9029553@news.demon.co.uk>...
>> Watch out for allocation of huge stack areas for aggregate assignments
>> to arrays...
>>     My_Large_Array = (others => 0, others => 0, others => 0);
>> 
>> will attempt to allocate a 4MByte or so block of stack to create an
>> aggregate before copying it to the global variable (My_Large_Array).
>> Green Hills claim it is *required* by the RM, but certain people who
>> were involved in writing the manual disagree!
>
>(assuming you meant ":=")

Of course!! :-) (I don't use Ada very often now so mistakes like this
are quite likely to happen!)

>I believe this would be required in certian situations if the source
>for the data came from overlapping parts of the same object.

True, it may be necessary in some cases, but in this particular case
this was not the case :-}

>Perhaps
>the answer you got was vendor shorthand for "there are some situations
>where this would be required, and we don't want to do the work
>required to recognise those situations and do something different."
>:-)

No - the answer was "according to RMxxxx (can't remember the exact
reference) we are required to do that!".

Re: AdaMULTI/Ada 95 for Bare Board

[Jim Gleason]

john.mccabe@emrad.ns.com (John McCabe) wrote in message news:<3c83596e.9029553@news.demon.co.uk>...
> Watch out for allocation of huge stack areas for aggregate assignments
> to arrays...
> 
> e.g.:
> 
> type Large_Array is array (1..100, 1..10, 1..1000) of integer;
> My_Large_Array : Large_Array;
> 
> procedure Initialise
> begin
>     My_Large_Array = (others => 0, others => 0, others => 0);
> end Initialise;
> 
> 
> will attempt to allocate a 4MByte or so block of stack to create an
> aggregate before copying it to the global variable (My_Large_Array).
> Green Hills claim it is *required* by the RM, but certain people who
> were involved in writing the manual disagree!

I don't believe Green Hills claimed this.  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.
I hope this clears this up.

Jim Gleason
Green Hills Software, Inc.

Re: AdaMULTI/Ada 95 for Bare Board

[John McCabe]

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....

Re: AdaMULTI/Ada 95 for Bare Board

[John McCabe]

On Tue, 05 Mar 2002 14:22:43 GMT, john.mccabe@emrad.ns.com (John
McCabe) wrote:

>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!

I have been in touch with Jim through email on this and, funnily
enough, it turns out that this feature that I was told by Green Hills
was *required* by the RM, has been fixed!

According to Jim, it was fixed in a Summer 2001 release of Green Hills
Ada. Funny that it shouldn't be a bug in Spring 2001, it should be a
*required* feature, but by Summer 2001 it isn't a *required* feature
any more and has been fixed!

So, while I apologise for pointing out the risks of a *feature* (bug)
that has now been fixed, it makes me wonder about the quality of GHS
tech support.

Re: AdaMULTI/Ada 95 for Bare Board

[John McCabe]

On Tue, 05 Mar 2002 14:22:43 GMT, john.mccabe@emrad.ns.com (John
McCabe) wrote:

>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!

I have been in touch with Jim through email on this and, funnily
enough, it turns out that this feature that I was told by Green Hills
was *required* by the RM, has been fixed!

According to Jim, it was fixed in a Summer 2001 release of Green Hills
Ada. Funny that it shouldn't be a bug in Spring 2001, it should be a
*required* feature, but by Summer 2001 it isn't a *required* feature
any more and has been fixed!

So, while I apologise for pointing out the risks of a *feature* (bug)
that has now been fixed, I can't say I'm very happy about the way my
report was handled!

On a more positive note, I would recommend AdaMulti (as long as I
didn't have to pay for it!). We really didn't have many problems with
it in the time I was using it (at least not that I noticed), and it
even got some of the 'private extension of a tagged type with a
discrimant' features right (which I seem to remember weren't handled
correctly by ObjectAda or Apex).

Performance of compiled code seemed reasonable, but we were using it
on VxWorks so they didn't have to worry too much about the RTS.

As far as IDE useability is concerned it was, I'd say, better than
Apex, but not as good as ObjectAda (Visual C++ environment is really
quite nice). Target debugging facilities were, on the whole, very
good, although at the time (up to 8 months ago) it was still fairly
easy to tell that the debugger was derived from a C/C++ model!

The only other thing I remember as being a nuisance was that when you
added source components to a build file, it rebuilt the whole system
(which took ages on our system)! I think this was to do with the way
that the build files were a project dependency. You could set an
option for the build files *not* to be included as a dependency, but
then it would ignore the fact you'd changed one!

As I say, I stopped using AdaMulti around 8 months ago and, on the
whole, it was a fairly pleasant experience.

John