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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b7857cb3cbabcf8d X-Google-Attributes: gid103376,public X-Google-Thread: ff6c8,b7857cb3cbabcf8d X-Google-Attributes: gidff6c8,public X-Google-Thread: 1108a1,b7857cb3cbabcf8d X-Google-Attributes: gid1108a1,public X-Google-Thread: 10db24,b7857cb3cbabcf8d X-Google-Attributes: gid10db24,public X-Google-Thread: f43e6,b7857cb3cbabcf8d X-Google-Attributes: gidf43e6,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Ada News Brief Date: 1996/10/15 Message-ID: X-Deja-AN: 189568637 references: <533utt$43p@ns1.sw-eng.falls-church.va.us> organization: New York University newsgroups: comp.lang.ada,comp.sw.components,comp.object,comp.software-eng,comp.edu Date: 1996-10-15T00:00:00+00:00 List-Id: Keith said "I'm not sure where this statement came from, but it's not quite correct. Ada 95 is very nearly upward compatible with Ada 83, so *most* correct and portable Ada 83 code is valid Ada 95 code with the same semantics. In one study I've read about, an program consisting of several tens of thousands of lines of Ada 83 code, which had not been written with Ada 95 in mind, required no changes whatsoever. Porting a program from Ada 83 to Ada 95 is typically no more difficult than porting from one compiler to another. " There are other potential difficulties in porting from Ada 83 to Ada 95 in practice besides the known incompatibilities: 1. Bugs in the original compiler that it did not catch. We have run into instances of this with every Ada 83 compiler we have dealt with so far. 2. Bugs in the new Ada 95 compiler. As OCS systems pointed out, for at least some time to come, every Ada 95 compiler will have some bugs. Indeed, given that we have had a fair amount of experience in running old Ada 83 compilers that are supposedly mature and finding bugs, maybe some time to come will be a while. Basically for any modern powerful programming language, it is likely that compilers have SOME errors. What one hopes is that this source of problems is small compared to other problems, and that is what we have found to be the case with GNAT so far, and I have heard similar anecdotal evidence for other Ada 95 compilers. 3. Rep clauses not implemented the same way. For example, last I knew, Ada Magic uses sparse array structures where the index type is an enumeration type with holes. GNAT used to do so as well, but we found that this generated critical incompatibilities with old Verdix code, and changed GNAT accordingly. There are *many* other cases of this kind of problem. Over time, this has been one of the most difficult areas to deal with, though by now, GNAT implements almost all the rep clauses we have run into. 4. Code that depends on implementation dependent details. For example, one of our large customers had a heck of a time tracking down a "bug" which turned out to be a case where a packed array of length (1 .. 32) of booleans was mapped to an external hardware address. The Verdix compiler, perfectly reasonably, loaded the entire 32-bit word to test one bit. GNAT perfectly reasonably, loaded only the byte containing the bit to be tested. Normally these two approaches would be identical, but their hardware could not handle byte addressing for this address. We "fixed" GNAT to do a word access in this case, but it was not of course a bug in GNAT. 5. Use of library packages, if code uses some vendor supplied package (e.g. Starlet on DEC), then of course porting it may be tricky. 6. Use of preprocessors that are either not available, or supported differently in the new Ada 95 environment. We have prepared a preprocessor that is available with the current version of GNAT that can be used to handle some of these cases. 7. Use of pragmas and attributes not supported in the new compiler. For example, when porting DEC code, there are some programs which use the DEC pragmas and attributes (e.g. Import_Valued_Procedure pragma or the Null_Parameter attribute) that can be hard to translate. That is why we have implemented all these pragmas and attributes in GNAT. That's not an exhuastive list, but the point is that the incompatibilities between Ada 83 and Ada 95 have NOT proved to be a major issue in porting existing Ada 83 code. It should also be said that our experience with GNAT is that we have been able to port a number of large programs (in the several hundred thousands of lines range) from Ada 83 to GNAT successfully, with a very reasonable amount of effort and as we go, this gets easier. Interestingly the reason it gets easier is not because of GNAT becoming generally more solid (issue 2 above), but rather because we keep implementing new functionality that alleviates other problems from the above list. In practice at this stage, we find that compiler bugs are a relatively small part of the porting issue. And yes, Keith is still right that the effort to port from Ada 83 to Ada 95 is comparable to porting from one Ada 83 to another Ada 83. This is the "distance" test that was established as a design requirement for the Ada 95 effort, and in practie, this criterion seems to have been met, which means that operationally Ada 95 is upwards compatible with Ada 83. However, no one should tell anyone that it is zero effort to move from Ada 83 to Ada 95. This is false, just as false as telling someone that it is zero effort to move from one Ada 83 compiler to another Ada 83 compiler. Sure, if a program has been *very* carefully written, and avoids implementation dependent features, it may be highly portable, but the real world of large scale applications is not in this category. Ada programs are typically highly portable, but it is important not to oversell this feature. I once heard the project director for the IBM air traffic control system say that Ada 95 must guarantee that their application move without changing a single line of code. The mere fact that someone could state this obviously unrealistic requirement worried me at the time, since it seems to me that anyone working with large Ada applications should have a more realistic view.