* GNAT Opinions @ 1998-12-23 0:00 choboy 1998-12-23 0:00 ` Bob ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: choboy @ 1998-12-23 0:00 UTC (permalink / raw) My company is currently considering converting a multi-program, multi- processor, Solaris-based application (~800K lines of code) written in Verdix Ada (SunAda3.0) to a "to be determined" Ada vendor. GNAT Ada95 is one of these compilers under consideration. I'm looking for opinions from people who may have used GNAT in a large-scale development effort such as ours or perhaps did some trade studies that resulted in a GNAT go/no-go decision. What were your experiences, good or bad? Why did you choose/not choose GNAT? Would you choose GNAT if you had to do it all over again? If you paid for and used the support from Ada Core Technologies, how was it? What kind of development tools did you use, for example full-screen debuggers? The answers to these and any other opinions you might have would be greatly appreciated. Bob Choboy -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-23 0:00 GNAT Opinions choboy @ 1998-12-23 0:00 ` Bob 1998-12-24 0:00 ` Pat Rogers 1998-12-26 0:00 ` GNAT Opinions Steven Hovater 1999-01-04 0:00 ` Pascal MALAISE 2 siblings, 1 reply; 12+ messages in thread From: Bob @ 1998-12-23 0:00 UTC (permalink / raw) We are in the process of migrating 1.1 Million lines of Verdix Ada83 (SGI IRIX and IBM-RS6000 AIX) and Green-Hills Ada83 (Solaris) to GNAT Ada95. We are going through ACT and they are extremely helpful and knowledgeable. So far the only problems have been with the tighter definitions of Ada95 vs Ada83. The debugger (gdb) is kind of weak compared to Verdix (Rational), but it is usable. The two problems which we haven't been able to fix yet are not Ada questions. We want to migrate to INTEL but the little/big endianess is a major problem with record representation definitions going over a communications circuit. The other problem of cross targeting the RAD6K (RS6000) with VxWorks from an INTEL machine, either Linux or NT, is not currently in anyones planning. Generally the experiences have been good. The increased tightness of 95 pointed up quite a few pending problems, such as Generic definition circularity which Verdix 83 let us get away with. We were able to remove some linked "c" code which was doing bit operations, since ada95 has the types and operations. The reasons for choosing GNAT are: 1. PRICE 2. There is a version for every system we have. 3. World wide support, including ACT. 4. PRICE 5. Didn't have to pay extra for multi-processor support as in Verdix. Hope this helps. cheers....bob choboy@calspan.com wrote in message <75rj7i$2cq$1@nnrp1.dejanews.com>... >My company is currently considering converting a multi-program, multi- >processor, Solaris-based application (~800K lines of code) written in Verdix >Ada (SunAda3.0) to a "to be determined" Ada vendor. GNAT Ada95 is one of >these compilers under consideration. I'm looking for opinions from people >who may have used GNAT in a large-scale development effort such as ours or >perhaps did some trade studies that resulted in a GNAT go/no-go decision. >What were your experiences, good or bad? Why did you choose/not choose GNAT? > Would you choose GNAT if you had to do it all over again? If you paid for >and used the support from Ada Core Technologies, how was it? What kind of >development tools did you use, for example full-screen debuggers? The >answers to these and any other opinions you might have would be greatly >appreciated. > >Bob Choboy > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-23 0:00 ` Bob @ 1998-12-24 0:00 ` Pat Rogers 1998-12-25 0:00 ` dewarr 0 siblings, 1 reply; 12+ messages in thread From: Pat Rogers @ 1998-12-24 0:00 UTC (permalink / raw) Bob wrote in message <75rvnq$h75@dfw-ixnews10.ix.netcom.com>... <snip> >The two problems which we haven't been able to fix yet are not >Ada questions. We want to migrate to INTEL but the little/big endianess is a >major problem with record representation definitions going over a >communications circuit. Since you mentioned it, endian-independent representation clauses can be written (although they are not easy to read, but then, they never require changes due to endianess). Norm Cohen wrote about how to do it in Ada Letters. I have a free package to support it, with a demo program, at my web site: http://www.classwide.com/products/freecode.htm An editor macro to help produce them is a good idea. --- Pat Rogers Training & Development in: http://www.classwide.com Deadline Schedulability Analysis progers@acm.org Software Fault Tolerance (281)648-3165 Real-Time/OO Languages ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-24 0:00 ` Pat Rogers @ 1998-12-25 0:00 ` dewarr 1998-12-27 0:00 ` endian-independent rep clauses (was Re: GNAT Opinions) Pat Rogers 0 siblings, 1 reply; 12+ messages in thread From: dewarr @ 1998-12-25 0:00 UTC (permalink / raw) In article <75tr9e$3h8$1@remarQ.com>, "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > Since you mentioned it, endian-independent representation > clauses > can be written (although they are not easy to read, but > then, they > never require changes due to endianess). Norm Cohen > wrote about how > to do it in Ada Letters. I have a free package to > support it, with > a demo program, at my web site: This approach solves only a limited part of the problem that people would like to solve. There are many variations of this problem that occur in actual practice, Consider one of the most fundamental, which is that you have an external data stream that produces a big endian integer as four consecutive bytes in big-endian order. There is no magic rep clause to cause a compiler on a little-endian machine to acquire this data "correctly". Indeed the difficulty may vary from machine to machine, on some machines a quite long and tedious sequence of instructions may be required to reassemble the data. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* endian-independent rep clauses (was Re: GNAT Opinions) 1998-12-25 0:00 ` dewarr @ 1998-12-27 0:00 ` Pat Rogers 1998-12-28 0:00 ` dewar 0 siblings, 1 reply; 12+ messages in thread From: Pat Rogers @ 1998-12-27 0:00 UTC (permalink / raw) dewarr@my-dejanews.com wrote in message <760d41$p6r$1@nnrp1.dejanews.com>... >In article <75tr9e$3h8$1@remarQ.com>, > "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > >> Since you mentioned it, endian-independent representation >> clauses >> can be written (although they are not easy to read, but >> then, they >> never require changes due to endianess). Norm Cohen >> wrote about how >> to do it in Ada Letters. I have a free package to >> support it, with >> a demo program, at my web site: > >This approach solves only a limited part of the problem >that people would like to solve. There are many variations >of this problem that occur in actual practice, > >Consider one of the most fundamental, which >is that you have an external data stream that produces a >big endian integer as four consecutive bytes in big-endian >order. There is no magic rep clause to cause a compiler on >a little-endian machine to acquire this data "correctly". >Indeed the difficulty may vary from machine to machine, on >some machines a quite long and tedious sequence of >instructions may be required to reassemble the data. I answer with more than a little trepidation, knowing that you are capable of arguing one side to "victory" only to then switch and argue the other side! :-) Seriously, I would consider the above to be a separate problem, since indeed a record rep clause will not handle it. It does what Norm said it does, and nothing more. --- Pat Rogers Training & Development in: http://www.classwide.com Deadline Schedulability Analysis progers@acm.org Software Fault Tolerance (281)648-3165 Real-Time/OO Languages ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: endian-independent rep clauses (was Re: GNAT Opinions) 1998-12-27 0:00 ` endian-independent rep clauses (was Re: GNAT Opinions) Pat Rogers @ 1998-12-28 0:00 ` dewar 0 siblings, 0 replies; 12+ messages in thread From: dewar @ 1998-12-28 0:00 UTC (permalink / raw) In article <7667t3$3kj$1@remarQ.com>, "Pat Rogers" <progers@NOclasswideSPAM.com> wrote: > dewarr@my-dejanews.com wrote in message > >Consider one of the most fundamental, which > >is that you have an external data stream that produces a > >big endian integer as four consecutive bytes in > >big-endian order. There is no magic rep clause to cause > >a compiler on a little-endian machine to acquire this > >data "correctly". Indeed the difficulty may vary from > >machine to machine, on some machines a quite long and > >tedious sequence of instructions may be required to > >reassemble the data. > > I answer with more than a little trepidation, knowing > that you are capable of arguing one side to "victory" > only to then switch and > argue the other side! :-) Well I should hope so, if you can't argue both sides of a technical issue, it must mean you don't understand the issue and therefore should not argue on either side :-) > Seriously, I would consider the above to be a separate > problem, since indeed a record rep clause will not handle > it. It does what Norm said it does, and nothing more. Yes, and seriously, that *is* the problem. Most people when they ask about this problem, and in particular when they ask about overriding the default bit order are after a solution for this "separate problem"! Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-23 0:00 GNAT Opinions choboy 1998-12-23 0:00 ` Bob @ 1998-12-26 0:00 ` Steven Hovater 1998-12-28 0:00 ` dewar 1999-01-04 0:00 ` Pascal MALAISE 2 siblings, 1 reply; 12+ messages in thread From: Steven Hovater @ 1998-12-26 0:00 UTC (permalink / raw) One thing to think about - if the application has been written to take advantage of such things such as the VADSexec packages - with it's support for the tailorable runtime, semaphores, mailboxes, etc. etc. you may find it easier to continue to use the code you have (in it's present state) and stick with the Rational compiler (e.g. VADS, or Apex). Depends on what you're trying to accomplish - do you have funding from your customer to rehost? (for example). Do you have to retrain your developers to use GNAT? BTW, I do happen to work for Rational, and spend all of my time with the Ada products in a direct hands-on onsite support role for my customers. Cheers, Steve choboy@calspan.com wrote: > My company is currently considering converting a multi-program, multi- > processor, Solaris-based application (~800K lines of code) written in Verdix > Ada (SunAda3.0) to a "to be determined" Ada vendor. GNAT Ada95 is one of > these compilers under consideration. I'm looking for opinions from people > who may have used GNAT in a large-scale development effort such as ours or > perhaps did some trade studies that resulted in a GNAT go/no-go decision. > What were your experiences, good or bad? Why did you choose/not choose GNAT? > Would you choose GNAT if you had to do it all over again? If you paid for > and used the support from Ada Core Technologies, how was it? What kind of > development tools did you use, for example full-screen debuggers? The > answers to these and any other opinions you might have would be greatly > appreciated. > > Bob Choboy > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- Steven Hovater svh@rational.com Software Engineering Consultant Phone/fax:781-676-2565/2500 Rational Software Pager: 888-906-2209 83 Hartwell Ave, Lexington, MA Amateur radio: AA1YH ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-26 0:00 ` GNAT Opinions Steven Hovater @ 1998-12-28 0:00 ` dewar 0 siblings, 0 replies; 12+ messages in thread From: dewar @ 1998-12-28 0:00 UTC (permalink / raw) In article <36859E9F.58605AB6@mediaone.net>, Steven Hovater <nh-ho@mediaone.net> wrote: > One thing to think about - if the application has been > written to take advantage of such things > such as the VADSexec packages - with it's support for the > tailorable runtime, semaphores, mailboxes, > etc. etc. you may find it easier to continue to use the > code you have (in it's present state) and stick > with the Rational compiler (e.g. VADS, or Apex). Depends > on what you're trying to accomplish - do you have funding > from your customer to rehost? (for example). Do you have > to retrain your developersto use GNAT? One interesting issue here is that the specs of some of these packages are copyrighted. In my opinion, it is far better for customers if the specs of such packages are not copyrighted in a restrictive manner. When developing applications in Ada, it is important to pay attention to whether vendor supplied libraries have copyrighted specs that will make porting difficult. Note that in the case of GNAT, we always ensure that specs are copyrighted in a manner that makes sure that it will be possible to move the specs to another implementation. This is one of the great advantages of using an open source software approach! That being said, the particular problem of copyrighted VADS packages has not proved an insuperable barrier for moving to GNAT by any means. The functionalities provided in these packages are directly available either in ADa 95 itself, or in GNAT supplied packages, so providing the necessary implementations to replace the VADS packages is not too difficult. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1998-12-23 0:00 GNAT Opinions choboy 1998-12-23 0:00 ` Bob 1998-12-26 0:00 ` GNAT Opinions Steven Hovater @ 1999-01-04 0:00 ` Pascal MALAISE 1999-01-07 0:00 ` Steven Hovater ` (2 more replies) 2 siblings, 3 replies; 12+ messages in thread From: Pascal MALAISE @ 1999-01-04 0:00 UTC (permalink / raw) choboy@calspan.com wrote: > I'm looking for opinions from people > who may have used GNAT in a large-scale development effort such as ours or > perhaps did some trade studies that resulted in a GNAT go/no-go decision. Knowing that Verdix products will soon not be supported (on Digital Unix at least) and considering the price of the APEX package, we are starting a similar study. At present, this is just a study which involves a double migration, from DU 4.0 to Linux and from Verdix to Gnat (in 95 mode). For the compiler quality, nothing to say, except that - gnat compiling policy is restrictive, and despite the *nice* gnatchop, it is difficult to maintain both versions with unique sources. It is difficult to insert gnat compilation within an existing (and Verdix oriented) ada CASE environment. - gnat reliability, as a compiler, looks good. It better detects unused and non initialized variables. No compiler bugs have been detected so far. - gnat has some (specific or ada 95?) constraints on representation clauses which have to be defined before the usage of the type which forbids to put them in private parts, by instance. For the scale and progress of our study, - we migrate the middleware (which is mainly in C with ADA interfaces) - we migrate a demonstration program in Ada 83 to Gnat in 95 - everything compiles so far, but no attempt hs been made to run the result, which tempers my remark about gnat reliability, but we forsee to achieve the migration by the end of Feb. - we don't use Ada Core Tech support As a conclusion, so far so good. This migration does not raise more problems than other migration (to decada or Aonix). -- Pascal MALAISE (priv) mailto:malaise@magic.fr (prof) mailto:malaise@fr.airsysatm.thomson-csf.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1999-01-04 0:00 ` Pascal MALAISE @ 1999-01-07 0:00 ` Steven Hovater 1999-01-07 0:00 ` dewar 1999-01-07 0:00 ` Michael F Brenner 2 siblings, 0 replies; 12+ messages in thread From: Steven Hovater @ 1999-01-07 0:00 UTC (permalink / raw) Well, speaking from a Rational viewpoint ( I'm a technical representative for Rational, spend all my time supporting the VADS and Apex accounts in our area), I'm a little taken aback by your comment regarding support for Verdix (now Rational) products on Digital Unix. I can say for certain that we have a version of the self-hosted VADS compiler (6.2.5) that runs on 4.0d. I have heard nothing officially regarding a pending termination of support for this product. It it true that our new technology (including Ada95) is going into the Apex product line(both Unix and NT). Suggest you contact your local Rational representative for further information. (see www.rational.com). Cheers, Steve Pascal MALAISE wrote: > choboy@calspan.com wrote: > > I'm looking for opinions from people > > who may have used GNAT in a large-scale development effort such as ours or > > perhaps did some trade studies that resulted in a GNAT go/no-go decision. > > Knowing that Verdix products will soon not be supported (on Digital Unix > at least) > and considering the price of the APEX package, we are starting a similar > study. > At present, this is just a study which involves a double migration, from > DU 4.0 to Linux and from Verdix to Gnat (in 95 mode). > > For the compiler quality, nothing to say, except that > - gnat compiling policy is restrictive, and despite the *nice* gnatchop, > it is difficult to maintain both versions with unique sources. It is > difficult > to insert gnat compilation within an existing (and Verdix oriented) ada > CASE > environment. > - gnat reliability, as a compiler, looks good. It better detects unused > and > non initialized variables. No compiler bugs have been detected so far. > - gnat has some (specific or ada 95?) constraints on representation > clauses > which have to be defined before the usage of the type which forbids to > put > them in private parts, by instance. > > For the scale and progress of our study, > - we migrate the middleware (which is mainly in C with ADA interfaces) > - we migrate a demonstration program in Ada 83 to Gnat in 95 > - everything compiles so far, but no attempt hs been made to run the > result, > which tempers my remark about gnat reliability, but we forsee to achieve > the migration by the end of Feb. > - we don't use Ada Core Tech support > > As a conclusion, so far so good. This migration does not raise more > problems > than other migration (to decada or Aonix). > > -- > Pascal MALAISE > (priv) mailto:malaise@magic.fr > (prof) mailto:malaise@fr.airsysatm.thomson-csf.com -- Steven Hovater svh@rational.com Software Engineering Consultant Phone/fax:781-676-2565/2500 Rational Software Pager: 888-906-2209 83 Hartwell Ave, Lexington, MA Amateur radio: AA1YH ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1999-01-04 0:00 ` Pascal MALAISE 1999-01-07 0:00 ` Steven Hovater @ 1999-01-07 0:00 ` dewar 1999-01-07 0:00 ` Michael F Brenner 2 siblings, 0 replies; 12+ messages in thread From: dewar @ 1999-01-07 0:00 UTC (permalink / raw) In article <36910C32.1A0543E7@magic.fr>, Pascal MALAISE <malaise@magic.fr> wrote: > gnat compiling policy is restrictive, and despite the > *nice* gnatchop, it is difficult to maintain both > versions with unique sources. It is difficult to insert > gnat compilation within an existing (and Verdix oriented) > ada CASE environment. Actually this is fairly straightforward, but it is definitely the sort of thing on which many users need help, we have helped a number of our supported customers do exactly this, and there are several succesful approaches that can be used, depending on issues such as whether or not preprocessing is used. > gnat has some (specific or ada 95?) constraints on > representation clauses which have to be defined before > the usage of the type which forbids to > put them in private parts. Just to be clear here, it is fine to put rep clauses in private parts, the prohibition is that a rep clause cannot come after the type is frozen. The freezing rules are actually pretty similar in Ada 83 and Ada 95. Adapting and dealing with problematic rep clauses is certainly one of the major support activities for us in dealing with legacy code. In our experience, the problem is often neither with GNAT nor with Ada 95, it is just that the original code is plain wrong, and was erroneously accepted by the Ada 83 compiler, or it was implementation dependent code that depended, e.g. on a particular implementation of the Size attribute. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GNAT Opinions 1999-01-04 0:00 ` Pascal MALAISE 1999-01-07 0:00 ` Steven Hovater 1999-01-07 0:00 ` dewar @ 1999-01-07 0:00 ` Michael F Brenner 2 siblings, 0 replies; 12+ messages in thread From: Michael F Brenner @ 1999-01-07 0:00 UTC (permalink / raw) > gnat compiling policy is restrictive, and despite the *nice* gnatchop, > it is difficult to maintain both versions with unique sources. This hits the nail on the head, that gnat requires a library system as a wrapper to maintain the read-only version being compiled, separately from the read-write version being developed. This is very similar to DEC Ada's and Alsys Ada's option of permitting a copy of the source code being kept in the library for debugging messages. Only in gnat, it is REQUIRED to put a copy of the code into the library. The problem is that all other Ada compilers prior to gnat have provided a library wrapper around their compiler, so the programmer did not have to develop tools to do this chore. The good point of this is that it saved gnat the effort of building the library wrapper, and therefore speeded up gnat development. The bad point is that we each have developed our own library wrappers for keeping track of the two version (or NOT keeping track of them as the case may be). However, I would like to suggest that this is not a compiler issue at all, but a developement environment issue, that is, an APSE issue, a library issue. APSE issues should be tracked, but they have little to do with the compiler itself. In tracking compilers you are interested in a triangle of concerns: (A) bugs detected at compile time (type 1 and type 2 errors) (B) performance of the generated code (memory and time and threads) (C) bugs in the compiler and how fast they are fixed The APSE (library, configuration manager, cross referencer, data flow diagrammer, calling tree displayer, debugger, automatic code generators like CASE tools, cohesion metrics, coupling metrics, volume metrics like sloc or complexity, database management systems, APIs to connect to java byte codes or x windows or whatever, libraries of objects like containers or networks, and so forth) should be tracked separately from the compiler (IMO). Mike Brenner ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-01-07 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1998-12-23 0:00 GNAT Opinions choboy 1998-12-23 0:00 ` Bob 1998-12-24 0:00 ` Pat Rogers 1998-12-25 0:00 ` dewarr 1998-12-27 0:00 ` endian-independent rep clauses (was Re: GNAT Opinions) Pat Rogers 1998-12-28 0:00 ` dewar 1998-12-26 0:00 ` GNAT Opinions Steven Hovater 1998-12-28 0:00 ` dewar 1999-01-04 0:00 ` Pascal MALAISE 1999-01-07 0:00 ` Steven Hovater 1999-01-07 0:00 ` dewar 1999-01-07 0:00 ` Michael F Brenner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox