* Magnavox consultant trashes Ada tools in IEEE Computer @ 1994-10-11 20:48 Gregory Aharonian 1994-10-13 14:52 ` Paul Slonaker 1994-10-17 23:48 ` TOM 0 siblings, 2 replies; 14+ messages in thread From: Gregory Aharonian @ 1994-10-11 20:48 UTC (permalink / raw) The October 1994 issue of IEEE COMPUTER has an article from Magnavox AFATDS which does a pretty good job of effectively trashing Ada in a public forum. Written by Joseph Skazinski (who obviously must have gotten burned by Ada tools while working on AFATDS), the report illustrates the protectionist weaknesses of the Ada Mandate vis-a-vis Ada vendors. Titled "Porting Ada: A Report From the Field", the article talks about AFATDS development across Intel 486 running SCO, HP9000 running HP UNIX and moving code back and forth. I quote partly in context, partly out of context, not that it makes much difference. "The lack of stable and easy-to-use Ada libraries necessitated the writing of many Ada procedures whose sole purpose was to interface with C/Unix routines." "(Unfortunately, the Alsys Ada environment and the Ada tools limited the size and number of files that could be compiled into a library.)" "The creation of multiple child libraries from the parent library was necessary because of type and procedural dependencies among Ada packages. This structure created very long compile times when a package library was modified and all dependent packages had to be recompiled. The compilation of all Ada and C source files took nearly 4 days on the HP9000, less than a day on the RISC machines, and close to a week on the Intel486 machines. (The equivalent amount of C or C++ would take considerably less time; for example, the GNU C++ compiler completed about 30,000 lines of code in about 12 minutes on an Intel 486 SCO machine)." "Further the immaturity of the Ada tools was evident when the library manager tool would corrupt a library during the compilation of an Ada source file. This corruption meant that the entire library and all dependent child libraries had to be rebuilt." "[data alignment problems]. If an unaligned chunk of memory was used for a variable, program execution halted. Attempting to use the Ada debugger to view the variable resulted in the debugger's crashing, a time-consuming annoyance." "Ada tool problems constituted the most significant hurdle in the porting effort. For example, the Alsys compiler running under SCO UNIX would crash if an executable's file name contained more than eight characters and would not display an error message to that effect. Given that most of our executable file names were based on Unix conventions, it took quite a while to solve this problem. Alsys did not have a solution, and we discovered the eight character limitation only by chance." "Because the project's executables were very large, some over 20 megabytes, we attempted to compile them with full or limited optimization to reduce their size. Unfortunately, our attempt at optimization failed to produce reliable executables and we abandoned it. When the debugger crashed, we often had to wait to minutes to reach the same breakpoint." "We also found declaration elaboration to be a very time-consuming process that Ada debuggers did not handle well. An error occuring during this process would terminate execution. The elaboration process greatly complicates debugging and may result in erroneous programs, because elaboration is determined at execution time and may vary based on timing issues. The best solution to this problem is to minimize elaboration." "Needless to say, it is not easy to localize a problem in an application with dependencies on hundreds of Ada files. This process took considerable time, and solutions were not always found. When we couldn't find a tool solution, we had to research another method to accomplish the task and modify the software accordingly." "The effort to port AFATDS to an Intel/SCO platform is still incomplete and is awaiting an Ada compiler upgrade that can pass the AFATDS messaging schema's large arrays to generic procedures." "If the DoD's dual-use strategy is to succeed, the DoD must also foster the development of reliable and affordable Ada tools." ==================== Makes me want to rush out and drop my current language and adopt Ada. And this from an article written by someone who will be as favorable to Ada as anyone, being a contractor to the Army. And yet the article pretty much erases any gains that the ASA's advertising campaign much have achieved (while at the same time contradicting the main point of the ASA's ads). Many of the insults made by Ada people against C/C++ being said about Ada by an Ada person. Fifteen years and hundreds of millions of dollars of Ada pork, and insiders are still complaining about the poor quality of Ada tools. Debuggers crashing, linkers not linking, Ada features not being used because they are unreliable, and my favorite, comparing a 12 minute compile time for some C code that is equivalent to some Ada code that took a week to compile. If such sentiments are common INSIDE the Mandated world, and reflect the reality of current Ada tool technology, then Ada dual-use efforts are guaranteed to fail outside the Mandated world. For ten years open and honest debate about Ada policies and problems in the Ada industry has been suppressed, ignored and ridiculed. There should be entire sessions at Tri-Ada devoted to this topic, instead of the sweeping-under-the-rug that the SIGAda organizers every year seem to do. More than ever, this year's Tri-Ada needs a debate on the Ada dual-use. You can't dismiss this article by saying the author is a crackpot, inaccurate, unprofessional, or whatever, as Skazinski is an independent consultant who worked as a senior engineer with Magnavox (though like many others, he had to wait until the project was over to speak the truth). Nothing in the current dual-use plan addresses these issues, even assuming that the DoD cared enough about Ada to give the tens and hundreds of millions of dollars needed to help commercialize Ada. The plan was prepared by people unwilling to break out of the rut of having the same old people using the same old techniques to promote Ada while ignoring tons of disturbing trends. This article is a disaster for Ada (which is even more ironic since the editor of IEEE Computer is at the Naval Postgraduate School - hint of a Army/Navy conspiracy to help undermine the Ada Mandate? Inquiring minds want to know). IEEE Computer goes out to tens of thousands of software professionals who now are going to have a stack of reasons to ignore considering and adopting Ada, thanks apparently to an Ada insider. But hey, have fun singing songs and passing out medals at Tri-Ada. Greg Aharonian ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-11 20:48 Magnavox consultant trashes Ada tools in IEEE Computer Gregory Aharonian @ 1994-10-13 14:52 ` Paul Slonaker 1994-10-13 20:35 ` Ariel Lieberman 1994-10-17 23:48 ` TOM 1 sibling, 1 reply; 14+ messages in thread From: Paul Slonaker @ 1994-10-13 14:52 UTC (permalink / raw) I found the article to which Greg refers to be very interesting. I'm particularly interested in figuring out the impact of the various design decisions on the portability of the system, and less interested in the specific tool issues. Still, I couldn't let this particular lapse on the part of the author, and Greg's amplification of it, go without comment. In article <CxJ0G3.B9x@world.std.com>, Gregory Aharonian <srctran@world.std.com> wrote: > The October 1994 issue of IEEE COMPUTER has an article from Magnavox AFATDS >which does a pretty good job of effectively trashing Ada in a public forum. >Written by Joseph Skazinski (who obviously must have gotten burned by Ada >tools while working on AFATDS), the report illustrates the protectionist >weaknesses of the Ada Mandate vis-a-vis Ada vendors. > "... The compilation of all Ada and C source files took > nearly 4 days on the HP9000, less than a day on the RISC machines, > and close to a week on the Intel486 machines. (The equivalent > amount of C or C++ would take considerably less time; for example, > the GNU C++ compiler completed about 30,000 lines of code in about > 12 minutes on an Intel 486 SCO machine)." This is carelessness on the part of either the author or the editor. Nowhere in the article (as far as I could find), and certainly not in this part of it, does the author mention any size metrics for AFATDS. Not even a lines of code count, so that one could do an overly simple linear extrapolation to estimate how long it would take the GNU C++ compiler to compile the entire AFATDS. (Ignoring, of course, any differences between C and Ada lines of code.) >... my favorite, comparing a 12 minute compile time for some C code that is >equivalent to some Ada code that took a week to compile. Greg apparently misunderstood Skazinski's [incomplete] point, and draws the egregiously incorrect conclusion. Paul Slonaker Intermetrics, Inc. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-13 14:52 ` Paul Slonaker @ 1994-10-13 20:35 ` Ariel Lieberman 0 siblings, 0 replies; 14+ messages in thread From: Ariel Lieberman @ 1994-10-13 20:35 UTC (permalink / raw) yet, another place where people who don't know how to dance blame the floor. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-11 20:48 Magnavox consultant trashes Ada tools in IEEE Computer Gregory Aharonian 1994-10-13 14:52 ` Paul Slonaker @ 1994-10-17 23:48 ` TOM 1994-10-19 2:07 ` Bob Duff 1994-10-24 22:26 ` Robert Monical 1 sibling, 2 replies; 14+ messages in thread From: TOM @ 1994-10-17 23:48 UTC (permalink / raw) In article <CxJ0G3.B9x@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes: > The October 1994 issue of IEEE COMPUTER has an article from Magnavox AFATDS > which does a pretty good job of effectively trashing Ada in a public forum. > Written by Joseph Skazinski (who obviously must have gotten burned by Ada > tools while working on AFATDS), the report illustrates the protectionist > weaknesses of the Ada Mandate vis-a-vis Ada vendors. > Titled "Porting Ada: A Report From the Field", the article talks about > AFATDS development across Intel 486 running SCO, HP9000 running HP UNIX and > moving code back and forth. I quote partly in context, partly out of context, > not that it makes much difference. > > "The lack of stable and easy-to-use Ada libraries necessitated the > writing of many Ada procedures whose sole purpose was to interface > with C/Unix routines." > > "(Unfortunately, the Alsys Ada environment and the Ada tools limited > the size and number of files that could be compiled into a library.)" > > "The creation of multiple child libraries from the parent library > was necessary because of type and procedural dependencies among Ada > packages. This sounds like a poor design, and a poor design will cause lots of recompilation due to type and data dependencies. If the principles of data abstraction are done correctly, this shouldn't have been a problem. Doesn't any body do software engineering anymore? I guess it's just easier to blame the tool rather than developing a good architecture. > This structure created very long compile times when a > package library was modified and all dependent packages had to be > recompiled. The compilation of all Ada and C source files took > nearly 4 days on the HP9000, less than a day on the RISC machines, > and close to a week on the Intel486 machines. (The equivalent > amount of C or C++ would take considerably less time; for example, > the GNU C++ compiler completed about 30,000 lines of code in about > 12 minutes on an Intel 486 SCO machine)." It compiled - yes, were the data abstractions correctly implemented? The strong compile time type checking and unit consistency checking take more time, but buy orders of magnitude of time when working under the gun in the integration lab. Experience shows me that I would rather have a computer detecting bugs (via type checking and unit consistency checking) early rather than having to find them the hard way in the lab. > > "Further the immaturity of the Ada tools was evident when the > library manager tool would corrupt a library during the compilation > of an Ada source file. This corruption meant that the entire > library and all dependent child libraries had to be rebuilt." > Did they evaluate the tools that they were going to use? Some tools work better on some platforms than on other ones, but responsible engineers should make sure that the tools work as advertised before using them. > "[data alignment problems]. If an unaligned chunk of memory was > used for a variable, program execution halted. Attempting to use > the Ada debugger to view the variable resulted in the debugger's > crashing, a time-consuming annoyance." > > "Ada tool problems constituted the most significant hurdle in the > porting effort. For example, the Alsys compiler running under SCO > UNIX would crash if an executable's file name contained more than > eight characters and would not display an error message to that > effect. Hmmmm Does SCO Unix run on top of DOS - I think a sixth grader could have figured that one out. I move files from the VAX to the PC every day - it's not the tool's fault - they all use the DOS file system. I think Mr.Skazinski missed the mark by saying that it was the Alsys compiler's fault, he should point the finger at himself or whoever decided on the platform. > Given that most of our executable file names were based > on Unix conventions, it took quite a while to solve this problem. > Alsys did not have a solution, and we discovered the eight character > limitation only by chance." ( Laughter! ) > > "Because the project's executables were very large, some over 20 > megabytes, we attempted to compile them with full or limited > optimization to reduce their size. Unfortunately, our attempt > at optimization failed to produce reliable executables and we > abandoned it. When the debugger crashed, we often had to wait > to minutes to reach the same breakpoint." > > "We also found declaration elaboration to be a very time-consuming > process that Ada debuggers did not handle well. An error occuring > during this process would terminate execution. The elaboration > process greatly complicates debugging and may result in erroneous > programs, because elaboration is determined at execution time and > may vary based on timing issues. The best solution to this > problem is to minimize elaboration." > > "Needless to say, it is not easy to localize a problem in an > application with dependencies on hundreds of Ada files. This > process took considerable time, and solutions were not always > found. When we couldn't find a tool solution, we had to > research another method to accomplish the task and modify the > software accordingly." > > "The effort to port AFATDS to an Intel/SCO platform is still > incomplete and is awaiting an Ada compiler upgrade that can pass > the AFATDS messaging schema's large arrays to generic procedures." > > "If the DoD's dual-use strategy is to succeed, the DoD must also > foster the development of reliable and affordable Ada tools." > I agree here. > ==================== > > > > Makes me want to rush out and drop my current language and adopt Ada. > And this from an article written by someone who will be as favorable to Ada > as anyone, being a contractor to the Army. And yet the article pretty much > erases any gains that the ASA's advertising campaign much have achieved > (while at the same time contradicting the main point of the ASA's ads). > Many of the insults made by Ada people against C/C++ being said about Ada > by an Ada person. > > Fifteen years and hundreds of millions of dollars of Ada pork, and insiders > are still complaining about the poor quality of Ada tools. Debuggers crashing, > linkers not linking, Ada features not being used because they are unreliable, > and my favorite, comparing a 12 minute compile time for some C code that is > equivalent to some Ada code that took a week to compile. Compile times are irrevelant if the code doesn't work. Ada's concept of unit consistency prevents me from hurting myself in that area. > > If such sentiments are common INSIDE the Mandated world, and reflect the > reality of current Ada tool technology, then Ada dual-use efforts are > guaranteed to fail outside the Mandated world. For ten years open and honest > debate about Ada policies and problems in the Ada industry has been suppressed, > ignored and ridiculed. There should be entire sessions at Tri-Ada devoted to > this topic, instead of the sweeping-under-the-rug that the SIGAda organizers > every year seem to do. More than ever, this year's Tri-Ada needs a debate on > the Ada dual-use. I have to agree with Greg - I personally would rather program in Ada all of the time, but the lack of built-ins to due the low level bit twiddling makes for ugly code (I like C in that regard), and the high price of compilers means that I'll program in C or Pascal at home. > > You can't dismiss this article by saying the author is a crackpot, inaccurate, > unprofessional, or whatever, as Skazinski is an independent consultant who > worked as a senior engineer with Magnavox (though like many others, he had to > wait until the project was over to speak the truth). A senior engineer could also mean that he is 20 years behind in technology. I am not saying that about Mr. Skazinski since I don't know all of the facts, but I work for a senior engineer that is in management that is at least 10 years behind the current technology and I know tenured professors that teach C the same way now as they did 20 years ago. Does this mean that they are right? I see part of my job now as educating by boss on current technology and bringing him into the 90's. My experience with Ada on real-time embedded systems has lead me as a software lead to recommend it to my customers (DOD and Non DOD alike). I program in C and will do so if my customers demand it, but I don't recommend it. I prefer Ada since (if I have a good comiler and toolset - Vendors are you listening?) it will be inherently a more reliable and maintainable system than I could put together in C (or in C++). I really have no biases against any language since they are just tools to get the job done. I try to use what works best for each particular job - and in embedded systems, Ada is what works best for me. > > Nothing in the current dual-use plan addresses these issues, even assuming that > the DoD cared enough about Ada to give the tens and hundreds of millions of > dollars needed to help commercialize Ada. The plan was prepared by people > unwilling to break out of the rut of having the same old people using the same > old techniques to promote Ada while ignoring tons of disturbing trends. > > This article is a disaster for Ada (which is even more ironic since the editor > of IEEE Computer is at the Naval Postgraduate School - hint of a Army/Navy > conspiracy to help undermine the Ada Mandate? Inquiring minds want to know). > IEEE Computer goes out to tens of thousands of software professionals who now > are going to have a stack of reasons to ignore considering and adopting Ada, > thanks apparently to an Ada insider. > > But hey, have fun singing songs and passing out medals at Tri-Ada. > > Greg Aharonian -- ******************************************************************************* / / /\ ---- Todd A Sorensen (505) 828-5611 / / / \ / tsorense@dasd.honeywell.com / / / / --- tas@dasd.honeywell.com / / / / / ---- ---- --- [Now a "dronie"] ******************************************************************************** ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-17 23:48 ` TOM @ 1994-10-19 2:07 ` Bob Duff 1994-10-19 11:17 ` Robert I. Eachus 1994-10-19 13:31 ` Magnavox consultant trashes Ada tools in IEEE Computer Robert Dewar 1994-10-24 22:26 ` Robert Monical 1 sibling, 2 replies; 14+ messages in thread From: Bob Duff @ 1994-10-19 2:07 UTC (permalink / raw) In article <1994Oct17.164852.1@delphi.dasd.honeywell.com>, TOM <tsorense@delphi.dasd.honeywell.com> wrote: >In article <CxJ0G3.B9x@world.std.com>, srctran@world.std.com (Gregory Aharonian) writes: >> The October 1994 issue of IEEE COMPUTER has an article from Magnavox AFATDS >> which does a pretty good job of effectively trashing Ada in a public forum. >> "The creation of multiple child libraries from the parent library >> was necessary because of type and procedural dependencies among Ada >> packages. > >This sounds like a poor design, and a poor design will cause lots of >recompilation due to type and data dependencies. If the principles of >data abstraction are done correctly, this shouldn't have been a problem. >Doesn't any body do software engineering anymore? I guess it's just easier >to blame the tool rather than developing a good architecture. It doesn't seem fair to blame the user for poor tools. It's really hard to design large systems in Ada that take advantage of all the fancy software engineering features and also yield reasonable compile times. I think child packages and the Distributed Systems annex of Ada 9X will solve these problems, though. >> This structure created very long compile times when a >> package library was modified and all dependent packages had to be >> recompiled. The compilation of all Ada and C source files took >> nearly 4 days on the HP9000, less than a day on the RISC machines, >> and close to a week on the Intel486 machines. (The equivalent >> amount of C or C++ would take considerably less time; for example, >> the GNU C++ compiler completed about 30,000 lines of code in about >> 12 minutes on an Intel 486 SCO machine)." This seems strange. I find it hard to believe that any Ada compiler would take days to compile 30,000 lines of code. That's about 5 lines per minute! The above doesn't exactly say that. It says it took 4 days to compile the whole Ada program (we don't know how big), and 12 minutes to compile 30,000 lines of C++. It does *not* say that the whole Ada program was 30,000 lines. So we have no information on how long it would have taken the C++ compiler to compile an equivalent program. Surely the Ada code was more than 30,000 lines. >It compiled - yes, were the data abstractions correctly implemented? The >strong compile time type checking and unit consistency checking take more >time, but buy orders of magnitude of time when working under the gun in the >integration lab. Experience shows me that I would rather have a computer >detecting bugs (via type checking and unit consistency checking) early >rather than having to find them the hard way in the lab. 4 days of compile time is ludicrous. I don't care how many consistency checks are done -- if it takes 4 days, productivity is going to be abysmal. >> "Ada tool problems constituted the most significant hurdle in the >> porting effort. For example, the Alsys compiler running under SCO >> UNIX would crash if an executable's file name contained more than >> eight characters and would not display an error message to that >> effect. > >Hmmmm Does SCO Unix run on top of DOS - I think a sixth grader could have >figured that one out. I move files from the VAX to the PC every day - it's >not the tool's fault - they all use the DOS file system. I think >Mr.Skazinski missed the mark by saying that it was the Alsys compiler's >fault, he should point the finger at himself or whoever decided on the >platform. No, SCO Unix does not run on top of DOS. It's a Unix OS for PC's, and I believe it has long file names, and it's a valid complaint if the compiler crashed when it saw them. GA, again: >> Fifteen years and hundreds of millions of dollars of Ada pork, and insiders >> are still complaining about the poor quality of Ada tools. Debuggers crashing, >> linkers not linking, Ada features not being used because they are unreliable, >> and my favorite, comparing a 12 minute compile time for some C code that is >> equivalent to some Ada code that took a week to compile. I find it hard to believe that the Ada compiler actually ran at 5 lines per minute. So I think GA is incorrectly comparing apples and oranges here. >Compile times are irrevelant if the code doesn't work. Ada's concept of >unit consistency prevents me from hurting myself in that area. You could check the consistency *by hand* in 4 days! Sheesh. You're not going to get any Ada converts by claiming that 4-day compile times are worth it because of some additional consistency checking. We need Ada compilers that are at least *close* to the speed of C and C++ compilers. - Bob -- Bob Duff bobduff@inmet.com Oak Tree Software, Inc. Ada 9X Mapping/Revision Team (Intermetrics, Inc.) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-19 2:07 ` Bob Duff @ 1994-10-19 11:17 ` Robert I. Eachus 1994-10-20 19:00 ` Magnavox consultant trashes Ada tools Richard L. Conn 1994-10-21 20:28 ` Magnavox consultant trashes Ada tools in IEEE Computer Ed Falis 1994-10-19 13:31 ` Magnavox consultant trashes Ada tools in IEEE Computer Robert Dewar 1 sibling, 2 replies; 14+ messages in thread From: Robert I. Eachus @ 1994-10-19 11:17 UTC (permalink / raw) I've been waiting for someone who knows to post the current size of AFATADS, but last I heard it was about 2 million SLOC. Four (8 hour) days to recompile everything works out to 1000+ lines a minute, 24 hour days it would be closer to 350. The truth is probably somewhere in that range. The less than a day figure on the HP Snake only puts a lower bound on the performance on that platform. How long does it take to compile a 2 million line C++ program in that environment? I'm pretty sure it has never been done on such a small machine, but Microsoft might have comparable answers on for the large RISC platforms... -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools 1994-10-19 11:17 ` Robert I. Eachus @ 1994-10-20 19:00 ` Richard L. Conn 1994-10-21 20:28 ` Magnavox consultant trashes Ada tools in IEEE Computer Ed Falis 1 sibling, 0 replies; 14+ messages in thread From: Richard L. Conn @ 1994-10-20 19:00 UTC (permalink / raw) I just pulled up an Ada SDA summary on version 3.3.N9 of AFATDS. It is 5.3M lines (counting end of lines) or 1.1M Ada statements (open semicolons). Version 3.3.N9 is pretty close to current. Rick ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-19 11:17 ` Robert I. Eachus 1994-10-20 19:00 ` Magnavox consultant trashes Ada tools Richard L. Conn @ 1994-10-21 20:28 ` Ed Falis 1994-10-23 15:41 ` Norman H. Cohen [not found] ` <leschkes.783014077@ferret> 1 sibling, 2 replies; 14+ messages in thread From: Ed Falis @ 1994-10-21 20:28 UTC (permalink / raw) In <EACHUS.94Oct19111734@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes: > I've been waiting for someone who knows to post the current size >of AFATADS, but last I heard it was about 2 million SLOC. Four (8 >hour) days to recompile everything works out to 1000+ lines a minute, >24 hour days it would be closer to 350. The truth is probably >somewhere in that range. The less than a day figure on the HP Snake >only puts a lower bound on the performance on that platform. > How long does it take to compile a 2 million line C++ program in >that environment? I'm pretty sure it has never been done on such a >small machine, but Microsoft might have comparable answers on for the >large RISC platforms... >-- > Robert I. Eachus Might also be interesting for someone in the know to post how much of that count is generic instantiations. (Having trouble keeping a firm tooth-hold on my tongue regarding that article). - Ed Falis, Alsys ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-21 20:28 ` Magnavox consultant trashes Ada tools in IEEE Computer Ed Falis @ 1994-10-23 15:41 ` Norman H. Cohen [not found] ` <leschkes.783014077@ferret> 1 sibling, 0 replies; 14+ messages in thread From: Norman H. Cohen @ 1994-10-23 15:41 UTC (permalink / raw) In article <Cy1I80.B9E@alsys.com>, falis@east.alsys.com (Ed Falis) writes: |> (Having trouble keeping a firm tooth-hold |> on my tongue regarding that article). I'd be interested in knowing the vintage of the compiler and other tools they were using. Was this Alsys's latest and greatest, or was it first-generation technology, or was it something in between? -- Norman H. Cohen ncohen@watson.ibm.com ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <leschkes.783014077@ferret>]
* Re: Magnavox consultant trashes Ada tools in IEEE Computer [not found] ` <leschkes.783014077@ferret> @ 1994-10-25 17:03 ` Bob Kitzberger 1994-10-25 18:06 ` Robert Dewar (was: Magnavox etc.) Michael Feldman 1 sibling, 0 replies; 14+ messages in thread From: Bob Kitzberger @ 1994-10-25 17:03 UTC (permalink / raw) srctran@world.std.com (Gregory Aharonian) writes: > This structure created very long compile times when a > package library was modified and all dependent packages had to be > recompiled. The compilation of all Ada and C source files took > nearly 4 days on the HP9000, less than a day on the RISC machines, > and close to a week on the Intel486 machines. (The equivalent > amount of C or C++ would take considerably less time; for example, > the GNU C++ compiler completed about 30,000 lines of code in about > 12 minutes on an Intel 486 SCO machine)." This is more than a bit misleading. In order to compare equivalent C, C++ and Ada compilation times, you have to add the time it takes to run a "make depend" and "lint" on the C/C++ code, since the Ada compiler is of course performing that functionality. Also, of course optimal recompilation technologies would preclude the need for many/most recompilations in situations like this. -- Bob Kitzberger +1 (916) 274-3075 rlk@rational.com Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Robert Dewar (was: Magnavox etc.) [not found] ` <leschkes.783014077@ferret> 1994-10-25 17:03 ` Bob Kitzberger @ 1994-10-25 18:06 ` Michael Feldman 1 sibling, 0 replies; 14+ messages in thread From: Michael Feldman @ 1994-10-25 18:06 UTC (permalink / raw) In article <leschkes.783014077@ferret>, Scott Leschke <leschkes@ferret.cig.mot.com> wrote: > >I bet Bob Dewar would have opinions/insight >on this one, especially given the model that GNAT has chosen. > Robert Dewar is probably trying to be polite and not flame you for calling him "Bob", so I'll do the flaming. He really does prefer "Robert"...:-) Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman - chair, SIGAda Education Working Group Professor, Dept. of Electrical Engineering and Computer Science The George Washington University - Washington, DC 20052 USA 202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet) ------------------------------------------------------------------------ Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/ ------------------------------------------------------------------------ "Non illegitimi carborundum." (Don't let the bastards grind you down.) ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-19 2:07 ` Bob Duff 1994-10-19 11:17 ` Robert I. Eachus @ 1994-10-19 13:31 ` Robert Dewar 1 sibling, 0 replies; 14+ messages in thread From: Robert Dewar @ 1994-10-19 13:31 UTC (permalink / raw) a WEEK of compile time on the 486!!! Gads, on my thinkpad, which is not such a fast 486 since it lacks an L2 cache, I figure I could compile 15 million lines of Ada using GNAT in a week, and that's using the crippled version of GNAT with all the debugging checks (the only version we distribute right now!) Just how big is this system anyway? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-17 23:48 ` TOM 1994-10-19 2:07 ` Bob Duff @ 1994-10-24 22:26 ` Robert Monical 1994-10-25 14:53 ` Esther Lumsdon 1 sibling, 1 reply; 14+ messages in thread From: Robert Monical @ 1994-10-24 22:26 UTC (permalink / raw) In all fairness to the Magnavox folks, Alsys has had its problems. And they were given that tool selection by their customer. When we used Alsys, we needed a fast compile cycle to work through the bugs in the tools. In those days, tech support was non-existant (at least to us, maybe they were all off helping Magnavox!). We used one of the first releases on the HP 700 series boxes. We no longer use Alsys. -- rob: i e-mail, therefore i am -- monical@walnut.csp.mmc.com -- v: 719-528-3777 f: 719-528-3848 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Magnavox consultant trashes Ada tools in IEEE Computer 1994-10-24 22:26 ` Robert Monical @ 1994-10-25 14:53 ` Esther Lumsdon 0 siblings, 0 replies; 14+ messages in thread From: Esther Lumsdon @ 1994-10-25 14:53 UTC (permalink / raw) I emailed the contact information for IEEE Computer to the poster who requested it, but it bounced. IEEE Computer, Oct. 94 issue Computing Practices editor: Paul Oman, Univ. of Idaho oman@cs.uidaho.edu 208-885-7219 Mr. Oman's introduction to his section appears on pg. 49. The article in question appears on pgs. 58-64. The short bio (and email address) for the author, Mr. Skazinski appears on pg. 64. -- -- Esther Lumsdon, speaking only for myself esther@cybernetics.net Seeking C/C++/Ada/Unix programming job in Raleigh/RTP, NC area Finally living where the sky is Carolina blue! ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1994-10-25 18:06 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-10-11 20:48 Magnavox consultant trashes Ada tools in IEEE Computer Gregory Aharonian 1994-10-13 14:52 ` Paul Slonaker 1994-10-13 20:35 ` Ariel Lieberman 1994-10-17 23:48 ` TOM 1994-10-19 2:07 ` Bob Duff 1994-10-19 11:17 ` Robert I. Eachus 1994-10-20 19:00 ` Magnavox consultant trashes Ada tools Richard L. Conn 1994-10-21 20:28 ` Magnavox consultant trashes Ada tools in IEEE Computer Ed Falis 1994-10-23 15:41 ` Norman H. Cohen [not found] ` <leschkes.783014077@ferret> 1994-10-25 17:03 ` Bob Kitzberger 1994-10-25 18:06 ` Robert Dewar (was: Magnavox etc.) Michael Feldman 1994-10-19 13:31 ` Magnavox consultant trashes Ada tools in IEEE Computer Robert Dewar 1994-10-24 22:26 ` Robert Monical 1994-10-25 14:53 ` Esther Lumsdon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox