* Re: AdaMULTI/Ada 95 for Bare Board [not found] <3C7CF687.15D36BBE@avionics.saab.se> @ 2002-03-04 11:13 ` Alfred Hilscher 2002-03-04 11:28 ` John McCabe 0 siblings, 1 reply; 9+ messages in thread From: Alfred Hilscher @ 2002-03-04 11:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-04 11:13 ` AdaMULTI/Ada 95 for Bare Board Alfred Hilscher @ 2002-03-04 11:28 ` John McCabe 2002-03-04 15:12 ` Martin Dowie ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: John McCabe @ 2002-03-04 11:28 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-04 11:28 ` John McCabe @ 2002-03-04 15:12 ` Martin Dowie 2002-03-04 20:16 ` Ted Dennison 2002-03-05 13:27 ` Jim Gleason 2 siblings, 0 replies; 9+ messages in thread From: Martin Dowie @ 2002-03-04 15:12 UTC (permalink / raw) > 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... ;-) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-04 11:28 ` John McCabe 2002-03-04 15:12 ` Martin Dowie @ 2002-03-04 20:16 ` Ted Dennison 2002-03-05 9:32 ` John McCabe 2002-03-05 13:27 ` Jim Gleason 2 siblings, 1 reply; 9+ messages in thread From: Ted Dennison @ 2002-03-04 20:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-04 20:16 ` Ted Dennison @ 2002-03-05 9:32 ` John McCabe 0 siblings, 0 replies; 9+ messages in thread From: John McCabe @ 2002-03-05 9:32 UTC (permalink / raw) 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!". ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-04 11:28 ` John McCabe 2002-03-04 15:12 ` Martin Dowie 2002-03-04 20:16 ` Ted Dennison @ 2002-03-05 13:27 ` Jim Gleason 2002-03-05 14:22 ` John McCabe 2 siblings, 1 reply; 9+ messages in thread From: Jim Gleason @ 2002-03-05 13:27 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-05 13:27 ` Jim Gleason @ 2002-03-05 14:22 ` John McCabe 2002-03-05 15:42 ` John McCabe 2002-03-06 13:26 ` John McCabe 0 siblings, 2 replies; 9+ messages in thread From: John McCabe @ 2002-03-05 14:22 UTC (permalink / raw) 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.... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-05 14:22 ` John McCabe @ 2002-03-05 15:42 ` John McCabe 2002-03-06 13:26 ` John McCabe 1 sibling, 0 replies; 9+ messages in thread From: John McCabe @ 2002-03-05 15:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: AdaMULTI/Ada 95 for Bare Board 2002-03-05 14:22 ` John McCabe 2002-03-05 15:42 ` John McCabe @ 2002-03-06 13:26 ` John McCabe 1 sibling, 0 replies; 9+ messages in thread From: John McCabe @ 2002-03-06 13:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-03-06 13:26 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3C7CF687.15D36BBE@avionics.saab.se> 2002-03-04 11:13 ` AdaMULTI/Ada 95 for Bare Board Alfred Hilscher 2002-03-04 11:28 ` John McCabe 2002-03-04 15:12 ` Martin Dowie 2002-03-04 20:16 ` Ted Dennison 2002-03-05 9:32 ` John McCabe 2002-03-05 13:27 ` Jim Gleason 2002-03-05 14:22 ` John McCabe 2002-03-05 15:42 ` John McCabe 2002-03-06 13:26 ` John McCabe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox