Estimating conversion of Ada 83 to Ada 95

Estimating conversion of Ada 83 to Ada 95

[Terry J. Westley]

We're converting a 640 KSLOC real-time, distributed simulation from
Ada 83 (VADS) to Ada 95.  I expect most of the work will be replacing
VADS-specific packages with Ada 95 library packages and POSIX packages.

Based on some limited conversion work we've already done, I'm using
162 LOC/Hour for converting from VADS to GNAT Ada 95 for those files
which include lots of special stuff such as OS calls, use of VADS
packages, use of Oracle Pro*Ada, etc.  For the rest, I figure it'll
be at least 5 times faster than that, for a conversion rate of
812 LOC/Hour.  This includes conversion, compilation, and testing.

I expect we'll use the GNAT Ada83 switch for the first pass, then
turn it off to see what happens.

Anyone have any evidence that I'm way off on this estimate?

--
Terry J. Westley, Principal Engineer
Veridian Engineering, Calspan Operations
P.O. Box 400, Buffalo, NY 14225
twestley@buffalo.veridian.com    http://www.veridian.com

Re: Estimating conversion of Ada 83 to Ada 95

[David C. Hoos, Sr.]

Terry J. Westley wrote in message <7jj9kr$2hr$1@news2.tor.accglobal.net>...
>We're converting a 640 KSLOC real-time, distributed simulation from
>Ada 83 (VADS) to Ada 95.  I expect most of the work will be replacing
>VADS-specific packages with Ada 95 library packages and POSIX packages.
>
>Based on some limited conversion work we've already done, I'm using
>162 LOC/Hour for converting from VADS to GNAT Ada 95 for those files
>which include lots of special stuff such as OS calls, use of VADS
>packages, use of Oracle Pro*Ada, etc.  For the rest, I figure it'll
>be at least 5 times faster than that, for a conversion rate of
>812 LOC/Hour.  This includes conversion, compilation, and testing.
>
>I expect we'll use the GNAT Ada83 switch for the first pass, then
>turn it off to see what happens.
>
>Anyone have any evidence that I'm way off on this estimate?
>
No.  Sounds pretty consistent with my experience.

We didn't use the ada83 switch at all, because we found very few
things that wouldn't compile -- e.g. changes in floating point
attributes, type constraints on generic parameters, etc.

We did find, however, that it was very useful to use the
pragma Use_VADS_Size, because there were lots of rep clauses of
the form X at 0 .. Natural'Size -1;

The fact that Natural'Size changed from 32 to 31 would have
caused lots of grief the first time around if we hadn't used
the pragma.

I'm curious, though what you plan to do about Pro*Ada, as this
one doesn't have a "clean" solution to my knowledge.

Re: Estimating conversion of Ada 83 to Ada 95

[Robert Dewar]

In article <7jjeq8$hs3@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> We didn't use the ada83 switch at all, because we found very
> few things that wouldn't compile -- e.g. changes in floating
> point attributes, type constraints on generic parameters, etc.

The Ada 83 is in the business of issuing extra error messages,
not making things compile! There are a couple of exceptions,
but they are minimal.
>
> We did find, however, that it was very useful to use the
> pragma Use_VADS_Size, because there were lots of rep clauses
> of the form X at 0 .. Natural'Size -1;
>
> The fact that Natural'Size changed from 32 to 31 would have
> caused lots of grief the first time around if we hadn't used
> the pragma.

Actually we recommend against using this pragma, since in
practice it can hide problems.

Note that Natural'Size did NOT change from 32 to 31, it changed
from implementation dependent (both 31 and 32 were OK values)
to specified (32 required).

Any code that relied on Natural'Size being 31 was poorly written
non-portable code.

You at least want to consider whether a port of this kind should
clean up stuff like this, and get the code right, rather than
maintain bad non-portable code with a nasty kludge like
Use_VADS_Size.

> I'm curious, though what you plan to do about Pro*Ada, as this
> one doesn't have a "clean" solution to my knowledge.

I am amazed that anyone would think that Use_VADS_Size was
clean. This was put in at the insistence of one customer who
was convinced that they could port without changing any code
at all (quite wrong in fact, but at the time they were adamant
in not changing any code).

When you reengineer code from Ada 83 to Ada 95, it is worth
considering using it as an opportunity to clean up junk code.
It is unlikely that it will get done in the future!



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Estimating conversion of Ada 83 to Ada 95

[Jean-Pierre Rosen]

David C. Hoos, Sr. a �crit dans le message
<7jjeq8$hs3@hobbes.crc.com>...
>
>Terry J. Westley wrote in message
<7jj9kr$2hr$1@news2.tor.accglobal.net>...
>>We're converting a 640 KSLOC real-time, distributed simulation from
>>Ada 83 (VADS) to Ada 95.  I expect most of the work will be
replacing
>>VADS-specific packages with Ada 95 library packages and POSIX
packages.
>>
>>Based on some limited conversion work we've already done, I'm using
>>162 LOC/Hour for converting from VADS to GNAT Ada 95 for those files
>>which include lots of special stuff such as OS calls, use of VADS
>>packages, use of Oracle Pro*Ada, etc.

Beware that Pro*Ada is very poorly written and works ONLY with VADS.
In my experience, the easiest path is to package your transactions in
a (small) C routine, use Pro*C, and then interface to the C routines.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Estimating conversion of Ada 83 to Ada 95

[Robert Dewar]

In article <7jj9kr$2hr$1@news2.tor.accglobal.net>,
  "Terry J. Westley" <twestley@buffalo.veridian.com> wrote:
>
> Anyone have any evidence that I'm way off on this estimate?

Based on our extensive experience with people converting from
VADS Ada 83 to Ada 95, I would say that no estimate like this
can be even vaguely complete.

It all depends on the quality of the original code. If people
have been careful to write nicely portable code, your estimate
is way high (and we have seen people do conversions with a
productivity of at least ten times this figure, and even higher
in some cases).

If on the other hand, the programmers have done a lousy job
of writing clean portable code, then it may take arbitrarily
long to do a conversion.

The best thing is to do some sample conversions of small pieces
of the system, to get a feeling for how well the code is
written.

Robert Dewar
Ada Core Technologies

P.S. If you are using GNAT for this conversion, ACT has
extensive experience in helping with such conversions, and
this is one area where our support services can definitely
be very useful.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Estimating conversion of Ada 83 to Ada 95

[Paul Hussein]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:7jk0do$hk$1@nnrp1.deja.com...
> In article <7jj9kr$2hr$1@news2.tor.accglobal.net>,
>   "Terry J. Westley" <twestley@buffalo.veridian.com> wrote:
> >
> > Anyone have any evidence that I'm way off on this estimate?
>
> Based on our extensive experience with people converting from
> VADS Ada 83 to Ada 95, I would say that no estimate like this
> can be even vaguely complete.
>
> It all depends on the quality of the original code. If people
> have been careful to write nicely portable code, your estimate
> is way high (and we have seen people do conversions with a
> productivity of at least ten times this figure, and even higher
> in some cases).
>
I agree whole-heartedly here having ported a real-time distributed sim in 83
to 95.
The problem is not in the porting itself, as this can be executed very
quickly, but in the testing and verification of the completed port.

The approach I took, which I stringly recommend is not to jump in the deep
end, but to gadually port your code. Take a look at all your code and assess
it for portability. Identify all those suspect non-portable units and
declarations and assumptions that are going to cause a problem. ( If found
the best way to do this was to take a small build of the system and compile
it with the new compiler.

Then attemp to fix the portability issues one at a time, and then test that
item with your original compiler until you are satisfied that it works.
Gradually shift your build to a portable build an a port, test, port test
cycle for each nom-portable issue. That way you are moving the build
gradually and in a controlled manner. You may then have a chance of having a
known build at the end of this process.

It does mean that you may not make the best use of all that 95 will give
you. However, if having a stable known build that you can work on under 95
is your goal, then this is the best approach. This principal holds true for
any porting really.


When the code is portable and in a known state,  then you can start
compiling with the 95 compiler to test that. Just that the build compiles in
no way means it will work. The advantage of doing it this way means you have
a fully working 83 build that you can probe and monitor to see what should
happen in your 95 build when you come across inconsistencies.

Most of my time was spent not on the porting itself, but on tracking down
these little inconsistencies.


Also I can recomend that whilst you are going to this effort, why not chuck
in another platform. I found it invaluable to have 2 to 3 platforms to build
the same code on. It gave extra insights into the portability issues that
the same compiler for your platform may mask over. In the end you may end-up
with a platform independant build aswell.

As for estimating, this is always very difficult. The actual mechanical
porting is relatively easy to estimate, but in my experience the problem is
estimating the little niggles that will be left. That is why I advocate
maintaining a portabe 83 build, and then it becomes less of a risk.


N.B. What you may find helpful, as I did initially to get a quick build
going, was to make use of some compatibility Ada packages that SGI produced
to aid in porting from VADS to  SGI GNAT. These reroduces lots of the VADS
packages but in GNAT form. They allowed quick assessment porting, and
insights in how one could replace them with standard Ada 95.


Hope this helps.

Anyone else feel free to comment.


> If on the other hand, the programmers have done a lousy job
> of writing clean portable code, then it may take arbitrarily
> long to do a conversion.
>
> The best thing is to do some sample conversions of small pieces
> of the system, to get a feeling for how well the code is
> written.
>
> Robert Dewar
> Ada Core Technologies
>
> P.S. If you are using GNAT for this conversion, ACT has
> extensive experience in helping with such conversions, and
> this is one area where our support services can definitely
> be very useful.
>
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Re: Estimating conversion of Ada 83 to Ada 95

[Robert Dewar]

In article <7jj9kr$2hr$1@news2.tor.accglobal.net>,
  "Terry J. Westley" <twestley@buffalo.veridian.com> wrote:
> I expect we'll use the GNAT Ada83 switch for the first pass,
> then turn it off to see what happens.

The GNAT Ada 83 switch is intended for those who are building
Ada 95 code that has for some reason to remain backwards
compatible with Ada 83. It is completely irrelevant for the
purposes of converting Ada 83 code to Ada 95.

Robert Dewar
Ada Core Tecnologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Estimating conversion of Ada 83 to Ada 95

[James E. Hopper]

We just finished a conversion from dec ada to gnat, and got nothing
like this!  Now since we had to modify dec ada constructs, you would
expect that  (starlet library for instance was a pain!)  But what i
would say is the same is the testing effort.  unless you already have
working unit tests and results, writing proper tests can take much more
tiem than the actual conversion.  i suppose you could just go straight
to integration testing, but i wouldnt feel comfortable with it.  if it
didnt work your estimates are going to go all to pieces while you go
back and test smaller units!

i would suggest a risk pot that has money to allow for this.  

jim

---------
In article <7jj9kr$2hr$1@news2.tor.accglobal.net>, Terry J. Westley
<twestley@buffalo.veridian.com> wrote:

> We're converting a 640 KSLOC real-time, distributed simulation from
> Ada 83 (VADS) to Ada 95.  I expect most of the work will be replacing
> VADS-specific packages with Ada 95 library packages and POSIX packages.
> 
> Based on some limited conversion work we've already done, I'm using
> 162 LOC/Hour for converting from VADS to GNAT Ada 95 for those files
> which include lots of special stuff such as OS calls, use of VADS
> packages, use of Oracle Pro*Ada, etc.  For the rest, I figure it'll
> be at least 5 times faster than that, for a conversion rate of
> 812 LOC/Hour.  This includes conversion, compilation, and testing.
> 
> I expect we'll use the GNAT Ada83 switch for the first pass, then
> turn it off to see what happens.
> 
> Anyone have any evidence that I'm way off on this estimate?
> 
> --
> Terry J. Westley, Principal Engineer
> Veridian Engineering, Calspan Operations
> P.O. Box 400, Buffalo, NY 14225
> twestley@buffalo.veridian.com    http://www.veridian.com

Re: Estimating conversion of Ada 83 to Ada 95

[Robert I. Eachus]

"Terry J. Westley" wrote:

> We're converting a 640 KSLOC real-time, distributed simulation from
> Ada 83 (VADS) to Ada 95.  I expect most of the work will be replacing
> VADS-specific packages with Ada 95 library packages and POSIX packages.

> Based on some limited conversion work we've already done, I'm using
> 162 LOC/Hour for converting from VADS to GNAT Ada 95 for those files
> which include lots of special stuff such as OS calls, use of VADS
> packages, use of Oracle Pro*Ada, etc.  For the rest, I figure it'll
> be at least 5 times faster than that, for a conversion rate of
> 812 LOC/Hour.  This includes conversion, compilation, and testing.

    If the Pro*Ada stuff is pervasive, the estimate is very optimistic.
Pro*Ada is the one area where I have found that you are often better off
rewriting using ODBC or some such.  Maybe you can convince Oracle to
create GNAT versions of the support packages for Pro*Ada, but in the
cases I have converted, using a vendor independent interface had two
benefits:

    1) I wouldn't have to do it again.
    2) The size of executables shrank significantly.
 
> I expect we'll use the GNAT Ada83 switch for the first pass, then
> turn it off to see what happens.

    You can, but I have never found much benefit from it.  It is much
more useful for making sure your code is Ada 83 compatible.

> Anyone have any evidence that I'm way off on this estimate?

    Pro*Ada is one that I almost mentioned on the Team Ada list.  I've
tried going the minimal conversion route and not been very happy.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...