GNAT Opinions

GNAT Opinions

[choboy]

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    

Re: GNAT Opinions

[Bob]

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

Re: GNAT Opinions

[Pat Rogers]

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

Re: GNAT Opinions

[dewarr]

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    

endian-independent rep clauses (was Re: GNAT Opinions)

[Pat Rogers]

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

Re: endian-independent rep clauses (was Re: GNAT Opinions)

[dewar]

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    

Re: GNAT Opinions

[Steven Hovater]

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

Re: GNAT Opinions

[dewar]

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    

Re: GNAT Opinions

[Pascal MALAISE]

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

Re: GNAT Opinions

[Michael F Brenner]

    > 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

Re: GNAT Opinions

[dewar]

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    

Re: GNAT Opinions

[Steven Hovater]

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