From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9b2d73e60acd3f07 X-Google-Attributes: gid103376,public From: "Paul Hussein" Subject: Re: Estimating conversion of Ada 83 to Ada 95 Date: 1999/06/09 Message-ID: <7jm29k$g67$1@lure.pipex.net>#1/1 X-Deja-AN: 487536586 References: <7jj9kr$2hr$1@news2.tor.accglobal.net> <7jk0do$hk$1@nnrp1.deja.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Complaints-To: abuse@uk.uu.net X-Trace: lure.pipex.net 928943220 16583 193.149.71.57 (9 Jun 1999 15:47:00 GMT) Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom X-MSMail-Priority: Normal NNTP-Posting-Date: 9 Jun 1999 15:47:00 GMT Newsgroups: comp.lang.ada Date: 1999-06-09T15:47:00+00:00 List-Id: Robert Dewar wrote in message news:7jk0do$hk$1@nnrp1.deja.com... > In article <7jj9kr$2hr$1@news2.tor.accglobal.net>, > "Terry J. Westley" 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.