Magnavox consultant trashes Ada tools in IEEE Computer

Magnavox consultant trashes Ada tools in IEEE Computer

[Gregory Aharonian]

    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

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Paul Slonaker]

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.

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Ariel Lieberman]

yet, another place where people who 

don't know how to dance blame the floor.

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[TOM]

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"]
********************************************************************************

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Bob Duff]

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.)

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Robert I. Eachus]

     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...

Re: Magnavox consultant trashes Ada tools

[Richard L. Conn]

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

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Ed Falis]

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

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Norman H. Cohen]

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

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Bob Kitzberger]

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

Re: Robert Dewar (was: Magnavox etc.)

[Michael Feldman]

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.)
------------------------------------------------------------------------

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Robert Dewar]

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?

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Robert Monical]

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

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Esther Lumsdon]

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!

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Douglas Rupp]

tsorense@delphi.dasd.honeywell.com (TOM) writes:

> 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.                                                                       
Just to set the record straight, SCO Unix doesn't now, nor has it ever used
the DOS file system.  Long ago there was a file name length limitation of
(I think) 14 characters.  Release 3.2v4 (the current release is 3.2v4.2)
removed any such restrictions.

In this case, it is indeed the tool's fault. 

As a long time user of Alsys Ada compilers on SCO Unix and HP 9000s
I would have to agree with one assessment made in the
original article.  The interaction of the compiler and tools with the
Unix environment on each of these machines is completely different.

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Bob Wells #402]

>      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.

G'day,
I've heard from a friend, who did a review of the design, that AFATADS
had 20 Unix processes and 400 Ada atsks running on a single workstation!
Bob W.

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Magnavox consultant trashes Ada tools in IEEE Computer
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



This originated from srctran@world.std.com (Gregory Aharonian)
and has been circulating among many postings:

>    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)."

I've seen a dozen commentaries that basically go like this:
    1) You didn't say how big the Ada code is
    2) How long would it take for an equivalent amount of C?
    3) You can't compare the compilation of a small C program to
        that of a very large Ada program - it's not fair.
    4) Combinations and variations of the above.

Has anyone besides me noticed that the statement was made in an
article - not this newsgroup - by a guy who probably doesn't read
this newsgroup and that the damage is done with respect to a
bunch of folks who probably also don't read this newsgroup?

If someone would publish the e-mail or snail-mail address of the
editor of IEEE COMPUTER, I'm sure we could all be doing something
MUCH MORE POSITIVE by sending HIM the list of gripes about how
this is an unfair characterization and asking HIM to clarify in
print what the real circumstances were? He probably still has the
phone number for Joseph Skazinski and could get him to clarify
and perhaps ANSWER the charges?

Sorry if I seem to be shouting - I'm not really. I'd just like to
see all this good commentary go to some sort of productive use
and - unless I'm grossly mistaken - sending it strictly to this
newsgroup is a little like preaching to the choir. Let's put the
noise out where it will do some good.

So how about it? Anyone out there have a copy of IEEE COMPUTER
handy (Greg? You started this.) and could maybe look inside the
front cover and see where the Esteemed Editor of said publication
might prefer to get his communications sent to? Might that get
posted out here sometime soon? Would those who've already posted
such eloquent criticsms of the aforementioned article care to
dredge them up off disk, clean them up a little and send them on?

Pax,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "A well-informed electorate being necessary to the security of a
    free state, the right of the people to keep and read books shall
    not be infringed."

        --  Anonymous commentary on the Second Amendment.
===============================================================================

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Nick Sizemore]

    From the October 1994 IEEE Computer:

    Editor in Chief            :  Ted Lewis    lewis@cs.nps.navy.mil

    Coomputing Practices Editor:  Paul Oman    oman@cs.uidaho.edu





   +------------------------------+---------------------------------+
   |N. L. Sizemore                | (602) 538-4883 [Voice]          |
   |Computer Sciences Corporation | (602) 538-4933 [FAX]            |
   |P.  O. Box 719                | sizemore@huachuca-emh17.army.mil|
   |Ft. Huachuca, AZ  85613-0719  |                                 |
   +----------------------------------------------------------------+
   |    "For aggregate success, members must be the same to the     |
   |    system and different to the environment."                   |
   |                                                                |
   |    Second Aggregate Law        in General Principles of        |
   |                                System Design                   |
   |                                Gerald & Daniela Weinberg       |
   +----------------------------------------------------------------+

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[CONDIC]

From: Marin David Condic, 407.796.8997, M/S 731-93
Subject: Re: Magnavox consultant trashes Ada tools in IEEE Computer
Original_To:  PROFS%"SMTP@PWAGPDB"
Original_cc:  CONDIC



EL>
EL>On Tue, 25 Oct 1994 14:53:00 GMT,
EL>Esther Lumsdon <esther@CYBERNETICS.NET> writes:
EL>
EL>I emailed the contact information for IEEE Computer to the poster
EL>who requested it, but it bounced.
EL>
The pathway out of my computer is not the same as the pathway
into it. Hence writing to me at the address I send from doesn't
work. I post my receive address in my trailer. Besides - I meant
for this info to go public so that those wishing to comment on
the piece in question could do so in a way which would be
*productive* (Getting this down, guys???)

EL>
EL>IEEE Computer, Oct. 94 issue
EL>Computing Practices editor:  Paul Oman, Univ. of Idaho
EL>oman@cs.uidaho.edu  208-885-7219
EL>Mr. Oman's introduction to his section appears on pg. 49.  The article
EL>in question appears on pgs. 58-64.  The short bio (and email address)
EL>for the author, Mr. Skazinski appears on pg. 64.
EL>
So there you have it ladies and gentlemen! An e-address for the
editor of IEEE Computer. Why not dust off all your gripes, clean
them up a little and send them out to him so that maybe some of
the more eloquent ones end up in the "letters" section and some
of the bad press for Ada can be mitigated?

It certainly won't take you any more time to do this than it did
to post the criticsms here where you're preaching to the choir.
EL>
EL>-- Esther Lumsdon, speaking only for myself     esther@cybernetics.net
EL>   Seeking C/C++/Ada/Unix programming job in Raleigh/RTP, NC area
EL>   Finally living where the sky is Carolina blue!
EL>
I have to agree That part of the country is some of the most
beautiful in the world. Never seen downtown Raleigh except from
I-95, but I've been to Chapel Hill and - if I couldn't live here in
Sunny Florida - I'd take NC as a very, very close second place.
Say "hi" to Andy and Opey for me.

Pax Vobiscum,
Marin


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-93                                      Technet:    796.8997
Pratt & Whitney, GESP                           Internet:   CONDICMA@PWFL.COM
P.O. Box 109600                                 Internet:   MDCONDIC@AOL.COM
West Palm Beach, FL 33410-9600
===============================================================================
    "A well-informed electorate being necessary to the security of a
    free state, the right of the people to keep and read books shall
    not be infringed."

        --  Anonymous commentary on the Second Amendment.
===============================================================================

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[Mitch Gart]

One reason for the long compile times was a bad interaction between
the Rational and Alsys toolsets.  Magnavox was composing their code
with Rational, then fairly late in the development cycle compiling it 
with Alsys.  Something about the Rational environment or editor caused 
Magnavox to go the direction of using lots of very deeply nested 
subunits, and lots of parent and child libraries.  Rational subsystems 
were mapped into Alsys parent-child libraries.  They were using a 
library structure with parent-child-grandchild... to at least 10 levels 
deep.  In the end they had a huge Ada program which was 

- as big or bigger than any program that had ever gone through the
  Alsys compiler

- structured in a very unusual way, with sub-libraries and subunits
  used much more heavily than "normal", whatever normal is

This combination seems to have brought the compile-time performance
of the Alsys compiler to its knees.  It seems to have exposed a
performance problem with very big programs whose library structure is
nested in this unusual way.

Whose fault is it, Magnavox, Rational, Alsys, Ada?  I don't know,
but it's too bad this had to get discussed in such a negative way.

	Mitch Gart

Re: Magnavox consultant trashes Ada tools in IEEE Computer

[David Emery]

Mitch wrote: 
>Something ...caused Magnavox to go the direction of using lots of
>very deeply nested subunits, and lots of parent and child libraries.
>Rational subsystems were mapped into Alsys parent-child libraries.
>They were using a library structure with parent-child-grandchild... to
>at least 10 levels deep. 

It's worth noting that I've seen similar problems with other compiler
systems.  A contractor that shall remain nameless once used a very
strict functional decomposition methodology with Ada.  Their mapping
to Ada was to use subunits.  So you ended up with:

	procedure Main is
          procedure Level1_Op1 is separate;
          procedure Level1_Op2 is separate;
        begin
          Level1_Op1;
          Level1_Op2;
	end Main;

	separate
	(Main)
	procedure Level1_Op1 is
	  procedure Level2_Op1 is separate;
          procedure Level2_Op2 is separate;
        begin
	  Level2_Op1;
	  Level2_Op2;
	end;

	separate
	(Main.Level1_Op1)
	procedure Level2_Op1 is ...

The compiler performance, by the time you got down to 
"separate (Main.Level1_Op1.Level2_Op1.Level3_Op1.Level4_Op1) 
 procedure Level5_Op1 is"

The compiler can have a heluva time creating the appropriate context
for a deeply nested subunit.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------