ada compilers

ada compilers

[Kjartan R. Gudmundsson]

I would like to know about Ada compilers for HP 9000/840 running HP-UX,
and for 386 unix boxes, (ibm ps/2-70). Please tell me about the compilers
you know of.

		thanks
###############################################################################
#                                     #                                       #
#	Kjartan R. Gudmundsson        # 
#	Raudalaek 12                  # 
#	105 Reykjavik                 #     Internet:  kjartan@rhi.hi.is      #
#       Iceland                       #     uucp:  ...mcvax!hafro!rhi!kjartan #
#                                     #                                       #
###############################################################################

Ada Compilers

[Kelvin W. Edwards]

I am seeking some information on validated Ada compilers for
use on any of the following computers:

	Commodore Amiga
	Apple MacIntosh
	SGI Iris 4D Series
	Sun MicroSystems (preferrably under SunOS3.4 or higher)

In particular,  does such a compiler exist and, if so, what are the 
hardware/software requirements for it ?  Also, does it have a 
good working environment ?  Any helpful experience you could pass on 
would also be appreciated.  Thanks in advance.

	Sincerely,
		 kelvin edwards

Re: Ada Compilers

[Robert Cousins]

I, too, am seeking information on validate ADA compilers.
The machine I am interested in is a 386 under Everex Unix (will
run Interactive binaries also).  Does anyone have any info?

Thankx

Robert Cousins
Speaking for myself alone.

A farewell to Ada

[Ted Holden]

 
 
 
      I've noticed that much of the present scholastic debate over Ada
involves fine points concerning the letter of the law (was Ada "intended"
to function in embedded systems etc.).  This is the kind of thing I expect
to see associated with losing causes.  Remember, the Apostle said
something like: "The letter of the law killeth, whereas the spirit giveth
life..."  People involved with winning causes are usually too busy making
money to be arguing over the letter of the law.
 
      The spirit of the Ada documents was never in doubt.  What was wanted
was a language which could be used for every kind of software project,
from embedded system to large database, and run on every kind of computer
system, from micro to mainframe.  Reasonable performance was expected on
all computers and for all projects.  Ability to run with minimal OS and
other language support was wanted.  Further, logical clarity and large-
scale re-usability of software was desired.
 
Journal articles indicate a continuing failure of Ada to work for embedded
systems as well as for large scale projects, a continuing failure to run
with acceptable performance on anything other than parallel or special-
purpose, expensive systems, and an actual gain in cross-system complexity
and decrease in the stated goal of reuseability.  In particular, the
ordinary systems which most people will be seeing in front of them for the
next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
 
C began with real machines, real programmers.  The idea seems to have
been:  
 
      "Lets take a hard look at this little PDP-7 and design a language
      which is one-to-one with its logical operations as many ways as
      possible (the plus-plus operator and register increments and so on)
      so that the code is as FAST as can be contrived, maximally easy to
      implement (so that next year when we get our PDP7.5 or whatever,
      we're back rolling in 2 weeks), and, within these constraints, is
      as amenable to human logic as possible in a no-nonsense, point-and-
      shoot kind of way, so that we end up with a kind of high-structured,
      low-level language; a thinking-man's assembler.  And then, let's
      write an operating system (UNIX) in that language so that, when we
      get our PDP-7.5, or the next year's computer, whatever it may be,
      we're REALLY back rolling two weeks later.
 
The maximal ease of implementation was achieved by making the core
language as small as possible, other functionality being left to the
operating system and to libraries, some standard amongst UNIX systems and
others peculiar to various other OSs and hardware bases for which C would
be implemented.  This allowed good and inexpensive C compilers to evolve
rapidly for PCs and other micros and, since the authors of those compilers
maintained the standard libraries as close as possible to the UNIX
implementations, C became the natural bridge between mid-sized and large
computers running UNIX and the micros.  
 
C thus achieved its present position of dominance in the mini-micro world,
and appears to be well poised for the future as well.  C++ appears to be
an entirely rational and intelligent extension of C, superimposing the
entire object-oriented paradigm including the features Ada leaves out.  
In particular, there appears to be no more than a 5% performance
degradation, if that, going from C to C++, at least judging from Turbo C
2.0 and the Zortech C++ compiler, and I assume the same will hold true
when you start seeing good native-mode C++ compilers for UNIX.
 
In fact, C++ appears to BE the very language which Ada was supposed to be
(the spirit of the law) but never can and never will be.  
 
Far from sharing this "real-world" sort of a heritage, Ada appears to have
its beginnings on the other edge of reality or non-reality, dependant on
one's point of view.  Ada appears to have been designed as a physical
embodiment of state-of-the-art principles of "software-engineering",
whatever that's supposed to mean, seemingly by assembling 300 committee
members in a room, having each draw up a maximum possible wish-list of
features for a programming language and/or operating system, and then
adding up all of the lists to a "standard", with any considerations of
real-world computers being regarded as unimportant. 
 
Ada is what you might expect from a programming language designed by
committee;  it is unbelievably slow, an unbelievable resource hog,
involves constant dilemmas over which is the real OS today, Ada or UNIX,
Ada or Dos etc. i.e. do we use Ada tasking, again frighteningly slow, or
ordinary UNIX tasking and inter-process communication, Ada source control
or SCCS, etc.  Naturally, the Ada task manager and the UNIX process
scheduler clash.  As for compiling, my experience has been that, with a
PC and lots of memory to play with, Ada compilers at least will get back
to you on the same DAY;  on a UNIX machine with ten other users doing
various other kinds of things, God forbid other Ada compiles, forget it.
 
The one thing which one might reasonably expect all of this slowness and
clunk to purchase, the one thing which might partially redeem the
situation were Ada to have it, is the object oriented paradigm: 
inheritance of classes and polymorphism.  Ada doesn't have it.
 
Most of the Ada journal articles begin with glowing headlines, and you
have to be able to read between the lines, but this isn't terribly
difficult.  For instance, a large section of articles in the December 88
Journal of Electronic Defense began with the title "Ada:  Maybe Not So Bad
After All". Remember, Ada has been around since 1979.  If that were the
best anybody could say about C after ten years, C compiler salesmen would
be starving and dying like flies.
 
     A senior Intel product marketing engineer is quoted on page 36 of the
same issue:  
 
      "the people who designed the Ada programming language were compiler
      experts, software experts - they weren't necessarily people familiar
      with real-time embedded systems."
 
Another article in the same issue describes the use of Ada in connection
with a real-time embedded digital signal processing application.  Since
Ada tasking could not be made fast enough for such work, the engineers
adapted a commercial run-time system, VRTX, and informed all programmers: 
 
 
     "Thou shalt not use Ada tasking, but rather VRTX tasking.
     "Thou shalt not use Ada dynamic memory allocation...
     "Thou shalt not use Ada generics; too slow...
 
and, when they finished with the "Thou shalt nots", what they had
left of Ada was a subset of Pascal which they had paid many thousands of
dollars for.  A far better Pascal compiler is produced by Borland and can
be had at B Dalton's for around $100.  Needless to say, the Rupe-
Goldbergesque system they ended up with was considerably less maintainable
than they might have gotten just using C.  This seems to be the rule.
 
The September/October 88 issue of Defense Computing carried a similar
article:  "Running in Real Time:  A Problem for Ada".  All other stories
concerning Ada and embedded systems read similarly.
 
     Does Ada work any better for large scale systems?  Another article
in the same Journal of Electronics Defense issue describing use of Ada on
the 1,246,000 line Army AFATDS system claims that:
 
      "Ninety percent of the software requirements were met with no major
      software problems."
 
as if this were good.  The man is claiming that he had major language-
related problems with 124,600 lines of code out of 1,246,000.  Again C
language is not noted for this kind of thing, nor would C be around if it
were.
 
     There was a recent DOD Computing Journal Article titled "Is Ada
Getting Better or Just Older?".  Again you don't read that sort of thing
about C.  There is the August 21 89 issue of Government Computer News
describing the problems which the huge FAA Advanced Automation System is
having due to IBM Ada implementations and tools (or lack thereof).  
 
     The SoftTech notes from the RICIS convention included mention of one
speaker's statement:  "Ada and UNIX doesn't work".  I've heard that a
million times from users, first time that succinctly in print.  Between
UNIX and Ada, UNIX is the real-world standard;  conflicts between it and
Ada will not be resolved in favor of Ada.  Hate to disillusion anybody...
 
     It would appear that the articles written by the real-time people are
saying "well, it isn't doing us any good but it must be working out great
for the mainframe guys, else why would we still be seeing it and be
ordered to use it?" and that the mainframe and database crowd is claiming
just the opposite.  Somebody must be hoping that nobody ever reads all of
these articles and starts putting two and two together.
 
      There are numerous problems associated with the fact that Ada
believes itself to be an OS, aside from the clashes between Ada and real
operating systems.  There is the further obvious problem that somebody
with a large mainframe/Cobol application which he thinks to port to a
UNIX/Ada system will need to redesign and rewrite his entire system from
scratch whereas, using C language, he might have written Cobol-callable
routines incrementally and had his application back up in a matter of days
or weeks instead of years.  There is no real way to call an operating
system from a Cobol program.
 
      The actual use of Ada is further complicated by three considerations
which really amount to theological problems INVOLVING Ada rather than
faults of Ada itself, but which, nonetheless, probably wouldn't exist if
Ada didn't exist.
 
First, the programming style being promulgated by DOD for Ada is anti-
conducive to the stated goal of readability;  it's like looking at a
thousand-page novel such as "War and Peace" with three or four lines of
programming code interspersed every second page or so.  The verbiage hides
the logic.  When every variable name looks like:
 
      "NUMBER_OF_CROWS_SALLY_ANNS_GRANDMOTHER_SHOT_WITH_HER_12_
      GAUGE_-LAST_TUESDAY",
 
then a single subroutine call (involving several such variables) can take
up a whole page.  In my own scheme of things, I try to keep literature and
programming separate.
 
Second, DOD is often insisting on portability via Ada rather than
portability via UNIX, POSIX calls etc.  This amounts to such things as
insisting, for instance, that vendors provide direct Ada hooks to a
database rather than simply writing an Ada -> C -> database hook.  Typical
vendor response is either "F... You" or "Manana".
 
A third is an over-emphasis on design, which often leads to grief in the
real-world.  I believe in designing in the large, nailing down interfaces
at tightly as possible, then rapid prototyping of individual modules,
followed by final design documentation and PDLs at low level.  I know of
numerous horror stories involving design-totally-then-code, but one very
recent one, naturally involving Ada, seems to top all.  
 
A military project involving Sun machines and Ada was abandoned after
something like 4 years and $30 million effort because of unacceptable
performance;  database screens were taking over a minute to come up.  The
design work had all been done according to your formula, the individual
modules had been designed, written, and tested, all according to the
standard military schedules and formulas (2167 etc.).  Everything seemed
hunky dory, only when they put the fricking thing together, it was too
damned slow to use.  And, the remarkable thing is, the very system the
military insists upon for management of software contracts prevented
anybody from knowing they were in trouble until four years and millions
had been blown.  The government people involved were essentially reduced
to the role of actors in a Greek tragedy.
 
Asked for a solution, my firm weighed the choice between offering an Ada-
to-C converter and silence, and opted for silence.
 
It sometimes seems to me that the Soviet military is kept backwards in
computers by a temporary lack of funds, while our military is required by
law to be backwards, and that may not be temporary.  Any rate, my guess
is that the general Russian skill with linguistics would prevent them from
ever being ensnared with Ada;  they would take one look and toss it. 
Slava Bogu.
 
      Ada threatens to leave DoD stranded and technologically backwards;
out of the mainstream of American computer science.  The better class of
programmers coming out of the schools will be used to the 2 second
compiles of Turbo C and Turbo Pascal.  Offer them jobs involving Ada, and
most if not all of them are probably going to give you the finger,
figuring they'd be happier selling used cars for a living.  
 
      There is the further problem of our present micro market being a
completely open system;  a representative of the KGB, the Turkish Empire,
the Green Dragon Tong, the successors to the AssHola Khomeini, Khadaffi,
or anybody else could walk into a B. Dalton's today and buy a copy of
Turbo C 2.0 or Zortech C++ for about $100.  Again, if I were the guy up
there getting into machine gun and rocket fights at 1600 mph, the last
thing I'd want to hear was that my machine guns and rockets were working
slower and/or less reliably than the other guy's because he bought a copy
of Turbo C at B. Dalton's, while my people were spending billions on Ada.
 
 
Ted Holden
HTE

Re: A farewell to Ada

[schmidt]

In article <14033@grebyn.com>, ted@grebyn (Ted Holden) writes:
>Ada is what you might expect from a programming language designed by
>committee;  it is unbelievably slow, an unbelievable resource hog,
>involves constant dilemmas over which is the real OS today, Ada or UNIX,
>Ada or Dos etc. i.e. do we use Ada tasking, again frighteningly slow, or
>ordinary UNIX tasking and inter-process communication, Ada source control
>or SCCS, etc.  Naturally, the Ada task manager and the UNIX process
>scheduler clash.  As for compiling, my experience has been that, with a
>PC and lots of memory to play with, Ada compilers at least will get back
>to you on the same DAY;  on a UNIX machine with ten other users doing
>various other kinds of things, God forbid other Ada compiles, forget it.

Along the same lines, lately I've heard a number of people make the
claim that:

  `There now exist Ada compilers that produce faster code than C/C++
  compilers.'

Naturally, taken out of context this statement doesn't mean very much,
since one can always find a lousy C/C++ compiler and an application
that brings out the worst in the compiler and vice versa for Ada.

Therefore, I'm curious to know what valid empirical studies have been
performed to compare `x' Ada compilers against `y' C/C++ compilers
across a representative set of benchmarks.  Furthermore:

1. Which `top-of-the-line' Ada compilers produce the best code?
2. How long do they take to compile non-contrived programs?
3. What are their resource constraints and requirements?
3. How reliable are they in practice?
4. And how much do they cost compared to `top-of-the-line' C/C++ compilers?

Without evidence of this sort the entire `language imperialism' debate
becomes egregiously religious.

Obviously, ``speed-of-generated-code'' or ``length-of-compile-time''
are not the only criteria by which to judge the success or failure of
a language.  However, since Ada supporters are beginning to make these
claims I'd like to see some supporting evidence!

thanks,

  Doug

Re: Ada

[William Thomas Wolfe, 2847]

From article <14033@grebyn.com>, by ted@grebyn.com (Ted Holden):
> Journal articles indicate a continuing failure of Ada to work for embedded
> systems as well as for large scale projects, a continuing failure to run
> with acceptable performance on anything other than parallel or special-
> purpose, expensive systems, and an actual gain in cross-system complexity
> and decrease in the stated goal of reuseability.  

   This is blatantly false; consider the November 1988 article
   in IEEE Software ("Large Ada projects show productivity gains"):

      After years of development and an initial skeptical reception,
      many people are now using Ada and saying that they like it...
      The growth in Ada's use has been helped by favorable reports
      from early adopters ("Ada Catches on in the Commercial Market,
      Soft News, IEEE Software, November 1986, p. 81) and by the
      growing number of validated compilers... project results show
      that Ada can greatly increase productivity for large systems...
      [in a 1.2-million-line Ada project] reuseable software developed 
      on the project was counted only once.  Roughly 13 percent of the
      delivered software was reuseable.  This reuse saved 190 man-months
      of effort (a 9-percent savings) and reduced the schedule by two
      calender months (a 4-percent savings)... Productivity for the
      execution environment -- including the operating system, data
      management, information management, communications support, and
      communications interface -- was 550 lines per man-month... 
      Productivity for the applications software... was 704 lines per
      man-month... the average productivity of the 1,500 systems in
      productivity consultant Lawrence Putnam's database: 77 lines
      per man-month (at the 1.2-million-line level)... 

   Sounds like a continuing *success* to me... 
   
> In particular, the
> ordinary systems which most people will be seeing in front of them for the
> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.

   Precisely the point of Dr. Charles McKay, head of the Software
   Engineering Research Consortium, in his Tri-Ada '88 presentation,
   "Standards for the Sake of Standards -- A Recipe for Failure".

   A prime example is Unix; the current POSIX effort aims to 
   standardize 1960's technology, thus resulting in a "lowest
   common denominator" which locks users into obsolescence.

   Ada's problem with Unix is that Unix, being 1960's technology,
   does not properly support lightweight processes.  Modernized 
   versions of Unix (e.g., MACH) which are designed to provide
   such support remove the difficulty.  Note that C or C++ programs
   making use of the same "heavyweight" tasking facility will be
   equally slow, since they rely on precisely the same system. 

   If one does not have to struggle with the limitations of *Unix*,
   then there is a wide selection of Ada compilers which run Ada 
   within that environment quite nicely.  Some, like the Telesoft
   TeleGen2 compiler, have global optimization facilities which
   result in better code than that which can be produced by current
   C compilers (as of Tri-Ada '88). 
   
> C began with real machines, real programmers.  The idea seems to have
> been:  [...] end up with a kind of high-structured, low-level language; 
> a thinking-man's assembler.  

   Yes, as one Usenetter's .signature states, "C combines the power
   of assembly language with the flexibility of assembly language".

   Fortunately, the economics of software development are in favor
   of using considerably higher-level languages.

> C++ appears to BE the very language which Ada was supposed to be
> (the spirit of the law) but never can and never will be.  

   Total rubbish; C++ retains all the low-level and dangerous
   facilities of C, which is obsolescent by modern software
   engineering standards.  As stated by Fairley (Software
   Engineering Concepts, page 228),  

      Modern programming languages provide a variety of
      features to support development and maintenance of
      software products.  These features include strong
      type checking, separate compilation, user-defined
      data types, data encapsulation, data abstraction,
      generics, flexible scope rules, user-defined exception
      handling, and concurrency mechanisms.  This chapter
      discusses these concepts...

   Now C++ has one useful feature which Ada does not: inheritance.
   But it is also (as its designer freely admits) lacking in
   generics and exception handling, and also does not provide
   a means of expressing concurrency in a standardized, portable way. 
   Since tools such as Classic Ada permit the use of inheritance with
   Ada (generating *standardized*, compile-it-anywhere code), this is
   something which can be worked around until Ada 9X brings it in directly. 

> Ada is what you might expect from a programming language designed by
> committee;  it is unbelievably slow, an unbelievable resource hog,

   This has been a property of some early Ada *compilers*, but is
   not a property of the Ada *language*.  Fortunately, compiler
   technology is now capable of delivering tight, efficient Ada
   object code, better than that being produced by C compilers.

   Compilation is slower because the Ada compiler is doing much
   more work for you; this reflects again the economics of software
   development in that machine time is cheaper than programmer time.

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation System is
> having due to IBM Ada implementations and tools (or lack thereof).  

   Are you saying that this is the fault of the *language*, or of IBM?

> There is no real way to call [Ada] from a Cobol program.

   Ada users can call COBOL or any other language using pragma
   INTERFACE; COBOL needs to have a similar standardized means
   of calling other languages.  Given that it does not, ad hoc
   means of calling other languages have been devised; there is
   no reason why such techniques cannot be used to call Ada just
   as well as C or any other language.  But this is COBOL's problem,
   not Ada's.  
    
> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

   To C hackers, who are accustomed to single-letter variables, yes.

   Software engineering specialists tend to have the opposite perspective.

> Second, DOD is often insisting on portability via Ada rather than
> portability via UNIX, POSIX calls etc.  This amounts to such things as
> insisting, for instance, that vendors provide direct Ada hooks to a
> database rather than simply writing an Ada -> C -> database hook.  Typical
> vendor response is either "F... You" or "Manana".

   And the response of the Ada community is to turn to companies
   such as The Ada Ace Group, Inc., a technical consulting company
   specializing in the development of Ada interface to software
   products and applications.  They provide customized pure Ada
   interfaces to existing commercial software products, such as
   databases, operating systems, and specific applications such 
   as X-Windows.  (Contact information: 4254 Indigo Drive, 
   San Jose, CA  95136; (408) 267-8296)  Do you really think the
   Ada community, with its emphasis on standardization and vendor  
   independence, is going to be stopped by an intransigent vendor?

> A military project involving Sun machines and Ada was abandoned after
> something like 4 years and $30 million effort because of unacceptable
> performance;  database screens were taking over a minute to come up.  The
> design work had all been done according to your formula, the individual
> modules had been designed, written, and tested, all according to the
> standard military schedules and formulas (2167 etc.).  Everything seemed
> hunky dory, only when they put the fricking thing together, it was too
> damned slow to use.  And, the remarkable thing is, the very system the
> military insists upon for management of software contracts prevented
> anybody from knowing they were in trouble until four years and millions
> had been blown.  The government people involved were essentially reduced
> to the role of actors in a Greek tragedy.
>  
> Asked for a solution, my firm weighed the choice between offering an Ada-
> to-C converter and silence, and opted for silence.

   How about applying a profiler and recoding the "hot spots"?
   If the slowness of Unix process handling is a problem, then
   a more modern version of Unix should be used.  Your company
   should have considered more than two options.

   There are problems in the government management process, but
   this pertains to the government and not to Ada.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[William Thomas Wolfe, 2847]

>> [...] There is the August 21 89 issue of Government Computer News
>> describing the problems which the huge FAA Advanced Automation System is
>> having due to IBM Ada implementations and tools (or lack thereof).  

    Apparently IBM has now changed its tune; its recent brochure
    entitled "Ada and IBM... Capability and Committment" states:

      IBM is committed to Ada.  Ada's support for modern software
      engineering concepts, its breadth of application, and its
      support for reuseable software components place it squarely
      in the forefront as a language of choice for both IBM's
      software engineers and for IBM's customers.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: A farewell to Ada

[Richard S D'Ippolito]

Painful as it was, I read your whole article, Ted.


When you say (in article <14033@grebyn.com>, Ted Holden):

>     Does Ada work any better for large scale systems?  Another article
>in the same Journal of Electronics Defense issue describing use of Ada on
>the 1,246,000 line Army AFATDS system claims that:
> 
>      "Ninety percent of the software requirements were met with no major
>      software problems."
> 
>as if this were good.  The man is claiming that he had major language-
>related problems with 124,600 lines of code out of 1,246,000.

how can you expect to be taken seriously?  Do you really believe the math
and premises behind your statement?  Wow!


Rich
-- 
We use kill ratios to measure how the war is going.
We use SLOC ratios to measure how our software is coming.
(Idea from Gary Seath)                                        rsd@sei.cmu.edu
-----------------------------------------------------------------------------

Ada Promises

[Doug Schmidt]

In article <7053@hubcap.clemson.edu>, billwolf%hazel (William Thomas Wolfe, 2847 ) writes:
>   This has been a property of some early Ada *compilers*, but is
>   not a property of the Ada *language*.  

I basically agree with this in principle, though Ganapathi and
Mendal's IEEE Computer article from February 1989 points out several
areas where the Ada's semantics of reordering operations restricts
code motion and strength reduction.  I'd assume that this penalizes
Ada on certain RISC processors since it limits the degree of
instruction scheduling possible.

>   Fortunately, compiler
>   technology is now capable of delivering tight, efficient Ada
>   object code, better than that being produced by C compilers.

Ironically, Ganapathi and Mendal conclude their article by stating
that:
 
  Use of the following Ada capabilities may hinder optimizations currently
  implemented in most Ada compilers:
  
  * exceptions
  * generic units
  * private and limited private types in package definitions
  * naming and modularity of package definitions, and
  * tasking

In other words, just about every major feature that differentiates Ada
from Modula 2 or Pascal exacts a penalty on optimization.  This is a
realistic and understandable phenomenon (C/C++ certainly contain their
share of features that disrupt optimization), but it also makes me
wonder just exactly what you mean with your claim that Ada compilers
produce better code than C compilers.

To avoid misunderstanding, can you please cite *specific* examples
(especially references to publically available literature) to support
your claim?  For example:

1. Precisely which Ada compilers produce better code than which C compilers?
   Not all compilers are created equal...

2. What are the benchmarks and where can they be obtained?  If, in
   order to generate good code, Ada programmers must limit themselves to
   a `Pascal subset' of the language exactly what advantages have
   accrued?

3. What are the hardware/OS platforms and what are the relative costs
   between the Ada and C compilers/environments?  After all, it is
   unfair to compare a $500,000 Rational Ada environment against
   a $120 copy of Turbo C on MS DOS ;-).

Without independently verifiable, empirical evidence it is difficult
to make an informed choice on this issue.  In the words of R. P.
Feynman:

  The fundamental principle of science, the definition almost, is this:
  the sole test of the validity of any idea is experiment.

Additional proof would greatly increase my confidence that Ada is more than
just another `promising' language (pun intended!).

thanks,

  Doug
--
Master Swordsman speak of humility;             | schmidt@ics.uci.edu (ARPA)
Philosophers speak of truth;                    | office: (714) 856-4034
Saints and wisemen speak of the Tao of no doubt;
The moon, sun, and sea speaks for itself. -- Hiroshi Hamada

Re: Ada

[Walter Rowe]

Ignore that last one ... got trigger happy ...
----------------------------------------------------------------------
>>>>> On 15 Nov 89 16:06:41 GMT, billwolf@hubcap.clemson.edu (Bill Wolfe) said:

billwolf> This is blatantly false; consider the November 1988
billwolf> article in IEEE Software ("Large Ada projects show
billwolf> productivity gains"):

billwolf> [...irrelevant text deleted...]
billwolf> on the project was counted only once.  Roughly 13 percent of
billwolf> the delivered software was reuseable.

Uhmmm ... correct me if I'm wrong here, but if a project is well
designed (ie. module specs are written to be general), I think there
would be a higher degree of re-usability for those modules, regardless
of the language used.  That's the purpose of writing generalized code.
Any good computer scientist/programmer knows that, right?

Imagine having to write sin(), cos(), etc, for every application you
needed them for.  This would of course be ludicrous, so those in the
know wrote good, generic routines to handle these functions and now
you take them for granted.

What I'm trying to say is that re-usability is not necessarily an
attribute of the programming language being used, but more likely it
is the result of using good system design techniques.  Who cares if
its C++, Ada, C, or Pascal?  If you approach the design correctly,
your solution will be general enough so as to apply to the greatest
number of variations of the same problem.  Thats what re-usability is
all about, isn't it?  Not re-inventing the wheel?

billwolf> Sounds like a continuing *success* to me ...

Sure, but so is Pascal (originally designed as a learning tool), but
its not highly used outside of Academia just like Ada is not highly
used outside of DoD.  Ever wonder why?
   
billwolf> A prime example is Unix; the current POSIX effort aims to
billwolf> standardize 1960's technology, thus resulting in a "lowest
billwolf> common denominator" which locks users into obsolescence.

I disagree.  Its not locking into obsolescence.  Its forcing one to
meet only a minimum set of requirements, which allows a maximum amount
of flexibility above and beyond those requirements.  As long as you
meet these minimum requirements, you still have the freedom to enhance
UNIX any way you see fit.  They aren't restricting you to these, but
saying that you must provide at least these things.

billwolf> Modern programming languages provide a variety of features
billwolf> to support development and maintenance of software products.
billwolf> These features include strong type checking, separate
billwolf> compilation, user-defined data types, data encapsulation,
billwolf> data abstraction, generics, flexible scope rules,
billwolf> user-defined exception handling, and concurrency mechanisms.

I have to agree with Bill on this point: more languages ARE beginning
to evolve into useful tools for productivity, rather than learning
tools, or tools intended for specific applications.  However, I think
in order to be most productive and efficient for a given application,
a language still must cater to that application to some extent (ie.
COBOL for record transaction processing, C for systems programming,
etc).

> [...] There is the August 21 89 issue of Government Computer News
> describing the problems which the huge FAA Advanced Automation
> System is having due to IBM Ada implementations and tools (or lack
> thereof).

billwolf> Are you saying that this is the fault of the *language*, or
billwolf> of IBM?

More than likely its IBM, although most of their projects seem to come
out of a committee, and in that respect, draw a striking resemblance
to Ada.  So, possibly both are at fault since Ada was designed by a
committee, too.  I think the basic point being made is that too many
hands in the pot spoil the soup, and I tend to agree with this.  Its
good to get outside opinions so that one can be as objective as
possible, but I still think that fewer people can supply a much more
rational decision.

> the programming style being promulgated by DOD for Ada [descriptive
> variable names] is anti-conducive to the stated goal of readability;  

billwolf> To C hackers, who are accustomed to single-letter variables,
billwolf> yes.  Software engineering specialists tend to have the
billwolf> opposite perspective.

Admittedly, I fall into the C hacker category, but I think Ted makes a
valid point here.  I'd much prefer to shuffle through a few pages of
documentation at the top of a print-out than have to look at unsightly
long variable/procedure/function names.  I support giving variables
meaningful names, just not unsightly long ones.

If the docs are good at the top of a file are good (ie. they clearly
and concisely convey the concept of what this code is suppposed to
do), then you shouldn't have to clutter the code with paragraph long
names.  You're trying to infer the logic being applied, not the
details of the individual statements (for alone they mean nothing
anyway).

billwolf> Bill Wolfe, wtwolfe@hubcap.clemson.edu

Walter Rowe, rowe@cme.nist.gov
---
My opinions are my own, and bare no reflection of the opinions
of the United States Government.

Re: Ada

[William Thomas Wolfe, 2847]

From rowe@cme.nist.gov (Walter Rowe):
> Sure, but so is Pascal (originally designed as a learning tool), but
> its not highly used outside of Academia just like Ada is not highly
> used outside of DoD.  Ever wonder why?

   The fact that good production-quality compilers have only been
   avaliable for the last year or two probably has a lot to do with it...

   Fortunately, as the IEEE Software article I cited demonstrates, 
   commercial use and acceptance of Ada is growing rapidly, both in 
   the US and overseas.  Non-DoD US users include General Electric, 
   Boeing Commercial Airplane, etc.; other companies, such as Arthur 
   Anderson, are considering converting to Ada now that the appropriate 
   compilers and tools are available.  Not because the DoD is using it,
   but as a simple result of business and engineering considerations. 

   Considering that the largest corporation in the WORLD, Nippon 
   Telegraph and Telephone, has maintained a committment to Ada 
   since 1982 (!!!), I'd say that Ada is certainly making excellent 
   progress in the commercial environment.  The fact that the
   DoD is requiring all its information systems work to be done
   in Ada is creating a great deal of infrastructure (e.g., the
   RAPID library of reuseable Ada information systems software
   components), which will further stimulate commercial use.  

   The experience so far has been that "once a team moved to Ada,
   they stayed with Ada.  Once Ada had been successfully used within
   a company, its use proliferated to other projects within the 
   company and to subcontractors and suppliers of that company within
   the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).  Given
   that high-quality compilers have only been available for a relatively
   short period of time, and that the US Ada market was already US $1.25 
   billion as of September 1987, I think the progress so far has been 
   quite substantial.  Watch comp.lang.ada for continued updates.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada compilers

[William Thomas Wolfe, 2847]

From schmidt@zola.ics.uci.edu (Doug Schmidt):
>>   Fortunately, compiler
>>   technology is now capable of delivering tight, efficient Ada
>>   object code, better than that being produced by C compilers.
> 
> 1. Precisely which Ada compilers produce better code than 
>    which C compilers? Not all compilers are created equal...

   The Telesoft TeleGen2 compiler, vs. all available C compilers,
   as of circa October 1988; contact Telesoft for details, since 
   the statement was made at the Telesoft User's Group meeting at
   the Tri-Ada '88 conference.  

> 2. What are the benchmarks and where can they be obtained?  If, in
>    order to generate good code, Ada programmers must limit themselves to
>    a `Pascal subset' of the language exactly what advantages have
>    accrued?

   I seem to recall "Dhrystone", among others, being cited.  There 
   were no limitations on the use of the Ada language.
 
> 3. What are the hardware/OS platforms and what are the relative costs
>    between the Ada and C compilers/environments?  After all, it is
>    unfair to compare a $500,000 Rational Ada environment against
>    a $120 copy of Turbo C on MS DOS ;-).

   I think the comparison might have focused on Sun workstations,
   but I'm by no means positive.  In any event, the point of contact is:

      TeleSoft, 5959 Cornerstone Court West, San Diego, CA, 92121-9891

   There were several articles in the Proceedings of Tri-Ada '88
   which considered at length the sophisticated optimization techniques
   which went into the TeleGen2 compiler; that might also be a good source. 
 
   There has been a new release of the TeleGen2 compiler since October 
   1988, and undoubtedly new releases of C compilers as well, so it 
   would probably be best to contact TeleSoft directly at the above 
   address for the most recent competitive statistics.  
    

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[ryer]

Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
SAA (Systems Application Architecture?) applications.  (SAA is IBM's big
new advance in portability and interoperability and a fundamental part
of their strategy for computing in the 90's).  If a program
is coded in Ada, it can't comply with SAA, regardless of any other
compatibility or interfaces.  Has this changed?  It is easy to write
a brochure, but where's the beef?

Mike Ryer
(personal comment, not endorsed by my employer, Intermetrics)

Ada allows one-char names (was Re: Ada)

[Steve Frysinger of Blue Feather Farm]

From article <ROWE.89Nov16140835@stella.cme.nist.gov>, by rowe@cme.nist.gov (Walter Rowe):
> billwolf> To C hackers, who are accustomed to single-letter variables,
 
> long variable/procedure/function names.  I support giving variables
> meaningful names, just not unsightly long ones.

I've been enjoying this debate, but for the sake of clarification I must
point out that Ada permits one-character variable names, and that most
C compilers I know allow variable names as long as Ada allows.  So I
submit that variable name length is irrelevant to this discussion.

Just wanted to keep folks who don't know Ada (or C) from misunderstanding!

Steve Frysinger

Re: A farewell to Ada

[Michael Schwartz]

OK.  You win. I have to put in my 2 cents' worth.  It's hard, because I
agree with many things that everybody has said.

Ada has been getting a bum rap.  Ada was not designed by committee, it
was designed by competition.  C, on the other hand, has been judged by
its applications.

Ada had no substantial applications to benchmark its design against.
The software engineering requirements imposed on Ada were for
programming in the large.  Precisely what Ada has been shown to be good
at.  Not surprisingly, Ada has not been found perfect for every
application area.  Where it has failed, Ada-9X proposals have been
submitted to change it.

C was developed for systems programming.  The worth of a compiler was
judged by the ability to build a good, modular, maintainable operating
system.  Where C failed, the language was changed.  And changed.  And
changed.

It has surprised no one that C is more responsive to change requests
than Ada.  Nor is it surprising that inexperienced software engineers
write better code in Ada than in C.  It has not escaped anyone's
attention that there are more inexperienced software engineers than
experienced software engineers.

Sorry for belaboring the obvious, but let's start somewhere.  Now let's
talk about Ada and Unix.  

Areas where Ada and Unix have problems:  a) System-dependent features
accessed from Ada b) Scheduler conflicts--Ada tasks vs Unix tasks c)
Ada image sizes and startup times

Of these areas, (c) is the most readily addressed.  I have heard a
number of Ada 9X proposals amounting to a mechanism to freeze the Ada
image after elaboration, but before execution.  So much for startup
times.  I have also heard several vendors tout smarter link-editors
which will help resolve image size problems.  I also hold hope for
shared library implementations; the Ada runtime can be shared among all
processes needing it.

Area (a) is one that requires Ada vendor support.  It is difficult to
think of a non-trivial software system without some system-dependent
feature.  After all, we buy different hardware precisely because of
these features.  In my mind, a major difference between a good Ada
compiler and a marginal one can be found in the support for operating
system signals, pragma interfaces, and representation specifications.
It is no anathema to me to have an Ada system contain bodies which are
Pragma Interface (C,...) EVEN IF I DON'T HAVE TO.  Maintenance costs
must be kept foremost.  Reducing maintenance costs is, after all, one
of the major considerations in developing Ada.  Let's not spoil this by
insisting that every Unix guru learn Ada.

Scheduler conflicts (b) remain a problem because Unix processes are not
the same as Ada tasks.  Several have pointed out that Ada tasks are
'lightweight'; they mean that Ada tasks are represented by different
execution threads (instruction pointers and stack frames) but the same
data space.  At least one Unix vendor has implemented a lightweight
process type in the Unix kernel.  It is possible that a good solution
will be to build an Ada compiler which maps its tasks to lightweight
Unix processes, letting the Ada scheduler be either eliminated or
vastly reduced.

In the absence of this solution, a multi-tasking Ada program must build
a monitor to mediate all operating system calls which may 'use up' its
most vital resource -- the Unix operating system process.  The
efficiency with which this may be done is directly related to both the
Ada compilation system's (ACS) ability to interface with Unix (see
(a)), and the 'goodness' of the Unix in question.

Since 'signals' are to Unix more or less what 'rendezvous' are to Ada,
the more events which can be propogated to the Ada monitor from Unix
via signals, the more efficient the implementation.  Broad support for
SIGIO seems to particularly help.

With current compiler technology, one published result we have obtained
is multi-tasking access through sockets within 20% of the performance
of a C program using standard fork() and exec() calls.  Both
applications were able to exchange over 5000 tcp/ip messages per
second with a cheap 68020 box.  Turning off the time-sliced tasking in
the Ada program helped significantly.

One other result is that using our Ada abstraction, new employees were
able to contribute to our project within one to two days, even with no
prior Unix experience.  Of course, a C abstraction is possible--but why
doesn't anyone use one?

A 'today' note: Dennis Ritchie spoke to the FRUUG (Front Range Unix
Users Group) last night about 9th Edition IPC.  He has developed a
different IPC abstraction for his research.  In syntax, it is similar
to our Ada (and C) abstractions.  Of course, it has kernel support :-).

There.  I feel better now ('thar she blows!)

Michael
-----------------------
schwartz@pogo.den.mmc.com  "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.

-- 
-----------------------
schwartz@pogo.den.mmc.com "Expect everything ... 
mschwartz@mmc.com                   and the unexpected never happens." 
ncar!dinl!schwartz                               --the phantom tollbooth

DISCLAIMER:  The opinions expressesed are not necessarily those of my 
	     employer or myself.

Re: Ada

[Pablo Fernicola]

In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>
>   Fortunately, as the IEEE Software article I cited demonstrates, 
>   commercial use and acceptance of Ada is growing rapidly, both in 

In IEEE Software, Vol.5 Num. 3 page 26, we read

	"C++ has several advantages over Ada: ..."

>
>   The experience so far has been that "once a team moved to Ada,
>   they stayed with Ada.  Once Ada had been successfully used within
>   a company, its use proliferated to other projects within the 
>   company and to subcontractors and suppliers of that company within
>   the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).  Given
		     ^^^^^^^^^^^^
		     Not a biased opinion, I hope :-)

A common syllogism nowadays is (from the same IEEE Software issue)

	Ada is good; object-oriented is good;
	therefore, Ada is object oriented.


>   Bill Wolfe, wtwolfe@hubcap.clemson.edu

BTW, it is good to hear from Bill again after the misc.jobs.misc debacle ...
--
pff@beach.cis.ufl.edu - Pablo Fernicola - Machine Intelligence Laboratory - UF
		IF YOU CARE ENOUGH TO READ SIGNATURES ...
	I am graduating next year and I am looking for a job.  
MS/BS EE, my graduate work incorporates OO-DBMS/Graphics/Robotics/AI

Re: Ada

[Marco S Hyman]

In article <7088@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
       Non-DoD US users include General Electric, 
       Boeing Commercial Airplane, etc.; other companies, such as Arthur 
       Anderson, are considering converting to Ada now that the appropriate 
       compilers and tools are available.  Not because the DoD is using it,
       but as a simple result of business and engineering considerations. 

Large corporations such ad GE, Boeing, Arthur Anderson, etc., are not known
for state-of-the-art, pushing-the-envelope solutions to their problems.
These are the companies that buy IBM.  Ada is safe, approved by the
government, and, as I once heard Larry Rossler of the HP Language Labs
describe it, doomed to success.  Too many companies are throwing money at it
to fail.

       The experience so far has been that "once a team moved to Ada,
       they stayed with Ada.  Once Ada had been successfully used within
       a company, its use proliferated to other projects within the 
       company and to subcontractors and suppliers of that company within
       the industry."  (Ada Letters, Vol. VIII, No. 5, page 15).

I don't have any facts or figures but I suspect from my own past experience
that this is true of every successful tool/method introduced to a large
corporation.  A manager that tries something new usually goes out on a limb
and therefore works twice as hard to make it succeed.  When it does succeed
that manager makes sure all of his bosses know that he was the hero that
finally brought a software project in on time and within budget.  Since
software projects are not usually on time or within budget the new
tool/method is seen as the solution to all software woes.  Alas, it's
usually just better management plus the productivity increase that comes
with doing something new that really saved the day.

I'm not saying the new tool/method, be it Ada, C++, OOP, or whatever, does
not help.  I just wish that it wasn't seen as a panacea for all that ails
the current problems in software.  (BTW:  the current problems in software
haven't changed, IMHO, in the last 20 years -- there's just a lot more
software.) But I've changed the subject.  Sorry.

C++ and Ada are just tools, folks.  Sometimes they are the correct
tool for the job.  Sometimes they are not.

// marc
-- 
// Marco S. Hyman		{ames,pyramid,sun}!pacbell!dumbcat!marc

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From ryer@inmet.inmet.com:
> Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
> SAA (Systems Application Architecture?) applications.  

   According to IBMers at Tri-Ada '89, Ada runs on three of the four
   platforms required for SAA-hood, and they're working on the fourth.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada

[William Thomas Wolfe, 2847]

From pff@beach.cis.ufl.edu (Pablo Fernicola):
> In IEEE Software, Vol.5 Num. 3 page 26, we read
> 
> 	"C++ has several advantages over Ada: ..."

   But unfortunately seems to be missing fundamental features
   such as exceptions, generics, and concurrency...

> A common syllogism nowadays is (from the same IEEE Software issue)
> 
> 	Ada is good; object-oriented is good;
> 	therefore, Ada is object oriented.

   Written by the designer of C++, whose definition of object-oriented
   is "Object-oriented programming is programming using inheritance".

   The definition of "object-oriented" varies widely, but even if we
   accept this definition, we need only obtain Classic Ada (or some 
   equivalent preprocessing product) in order to use inheritance in
   an Ada environment, pending more direct support in Ada 9X.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 
   

Forward into the past

[Dick Dunn]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes about UNIX and the Ada<->UNIX conflict that Ted Holden had
commented on:

>    A prime example is Unix; the current POSIX effort aims to 
>    standardize 1960's technology, thus resulting in a "lowest
>    common denominator" which locks users into obsolescence.

I picked this out of the latter half of an article where Bill was objec-
ting to Ted saying things that were "blatantly false" (Bill's words).  Bill
ought to be a little more careful about his own blatant falsehoods.

The POSIX work does, in fact, standardize some things which existed in the
'60's.  But it also covers mechanisms introduced in the '70's (e.g., job
control) and even into the latter part of the '80's (such as the "session"
mechanism).  Wouldn't it be rather disturbing to have a standard which
*excluded* technology older than 1970?!?

Standards are developed in two ways--either they codify existing practice,
or they attempt to constrain future practice.  Most standards in computing
are of the former sort.  The danger of a "codification" standard is, as
Bill obliquely points out, that it doesn't provide any guidance for the
future.  However, it does NOT lock people in; they are free to experiment
with extensions to this type of standard.  As new practice emerges beyond
the old standard, a basis for a successor standard is built.  Defining a
standard _a_priori_ without the benefit of existing practice is much harder
to get right.  You have to use the best research available to you, and hope
it's right.  It's sometimes necessary; sometimes an industry can't hope to
move forward without a standard.  (Consider TV, CDs, etc.)  Ada is in this
second class of standardization (unlike almost all other programming
languages).  It would help a lot if people who advocate either approach to
standardization would be less parochial and realize the tradeoffs.

>    Ada's problem with Unix is that Unix, being 1960's technology,...

Careful there!  People who live in glass houses...

To the extent that UNIX is 1960's technology, Ada is 1950's technology
and UNIX is the more modern of the two by a decade!  I'm serious...the
basic control structures, not to mention the "look and feel" of algorithmic
languages, was pinned down by the end of the 50's; it took another two years
to get it canonized in Algol 60 (with the "real" report out in '62).  Sure,
if I'm going to characterize Ada as a "'50's language" I have to ignore a
lot of important characteristics--but no more than are ignored by charac-
terizing UNIX as "1960's technology".

>    [UNIX] does not properly support lightweight processes...Modernized 
>    versions of Unix (e.g., MACH) which are designed to provide
>    such support remove the difficulty...

Bill is one of the people who has been arguing (over in comp.software-eng)
against the value of having a heavy operating systems course in a CS
curriculum...yet here we find that he thinks Mach is a "modernized version
of UNIX"???  I've seen trade rags muddle it that way, but it's wrong...
UNIX and Mach are not even the same type of animal.  But the more signifi-
cant misunderstanding is the idea that somehow lightweight processes should
have been in UNIX long ago.

The reason we have only recently seen a more widespread implementation of
lightweight processes is that it's only recently (meaning within the last
few years) become reasonably well understood just what the abstraction of a
"lightweight process" should be.  The understanding has been evolving along
with various experiments in hardware parallelism of various granularity.
The problem was not a matter of finding a workable abstraction, but of
choosing the right one(s).  The approach, in the UNIX community in
particular, is to try things first in research work, then let them gain
some wider experience in the more avant-garde places in industry, bring
them into the mainstream, and finally standardize them.  This cannot help
but look strange in the Ada world where standardization comes first and is
followed by trial.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: Ada & IBM

[Dick Dunn]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,
2847 ) writes in response to Ted Holden's comments about problems...
> >> ...due to IBM Ada implementations and tools (or lack thereof).  

>     Apparently IBM has now changed its tune; its recent brochure
>     entitled "Ada and IBM... Capability and Committment" states:

>       IBM is committed to Ada...

So what?  First, Ted did not address the question of whether IBM is
committed to Ada; he was talking about a report of real-world problems.

Second, "commitment" is not measured by glowing words in a brochure.  Do
you really think IBM would put out a brochure that said "Well, we're not
really keen on Ada, but it looks like we need it..."?

Wanna buy a bridge?  I'm committed to selling you the finest bridge.  It's
got support for modern engineering...hey, it supports lots of things.  It's
got breadth of application...you can apply it to any need as broad as the
bridge is wide...

Sheesh...it's marketing.  Do you believe every piece of advertising you
read?  Find out what's behind it.

What has IBM got for Ada?  Better yet, if you want to measure commitment,
find out how much new software THEY're writing in Ada (as opposed to
assembly language, or PL/S, or C, or...)

Do you really want a bold commitment from the company that gave us PL/I?
(Save the flames...yes, I know a lot of good software was written in PL/I.
It's still uglier than yesterday's roadkill.)
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

This has gotten stupid!

[Dick Dunn]

> > 1. Precisely which Ada compilers produce better code than 
> >    which C compilers? Not all compilers are created equal...
>    The Telesoft TeleGen2 compiler, vs. all available C compilers,
>    as of circa October 1988; contact Telesoft for details...

Oh, right, Telesoft is the unbiased judge of the universal superiority of
its own compiler!

>    the statement was made at the Telesoft User's Group meeting at
>    the Tri-Ada '88 conference.  

In other words, they made the statement in what amounts to a mutual ad-
miration society meeting.

> > 2. What are the benchmarks and where can they be obtained?...

>    I seem to recall "Dhrystone", among others, being cited.  There 
>    were no limitations on the use of the Ada language.

You "seem to recall"???  Your grandiose boasting is based on something you
don't quite remember?  Even if the one you think you remember is correct,
it's a tiny synthetic benchmark with well-known problems (acknowledged by
the author) and it is NOT suitable for comparisons of compilers.

> > 3. What are the hardware/OS platforms and...

>    I think the comparison might have focused on Sun workstations,
>    but I'm by no means positive...

But soft! 'Tis fair Amnesia come to stay a while.  Isn't it convenient how
little information there is here?  It's probably a comparison against pcc.

Bill told us that, thanks to sophisticated compiler technology, Ada
compilers can now give us better object code than C compilers.  But the
claim apparently applies only to one Ada compiler; the claim is made by
the vendor of that compiler; the claim is reported at a meeting for users
of the compiler; the benchmarks and hardware platforms used for the com-
parison are conveniently forgotten.

Pure vapor.

Bill, you argue best for Ada when you don't post.

Does anyone have any substance about code-generation quality of Ada
compilers?  I think it's a potentially interesting subject.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

interesting statistic

[Dick Dunn]

Wolfe wrote:
[about Ada]
|    The fact that good production-quality compilers have only been
|    avaliable for the last year or two probably has a lot to do with it...
...and later in the same article...
|    Considering that the largest corporation in the WORLD, Nippon 
|    Telegraph and Telephone, has maintained a committment to Ada 
|    since 1982 (!!!), I'd say that Ada is certainly making excellent 
|    progress in the commercial environment...

Considering those two together, I'd say Ada's appeal must be nothing short
of amazing!  Call it two years that production-quality compilers have been
available, i.e., 1987...

I guess we can conclude that NTT maintained a commitment to Ada in spite of
a five-year lack of production-quality compilers???
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...`Just say no' to mindless dogma.

Re: Ada & IBM

[Liam R. E. Quin]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu wrote:
>    [...] "Ada and IBM... Capability and Committment" states:
>      IBM is committed to Ada.  Ada's support for modern software
>      engineering concepts, its breadth of application, and its
>      support for reuseable software components place it squarely
>      in the forefront as a language of choice for both IBM's
>      software engineers and for IBM's customers.

No doubt the simple elegance of Ada appealed to IBM, depite their well-known
dislike of such small languages.

Lee

:-)
-- 
Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!]
lee@sq.com (Whilst visiting Canada from England)
lee@anduk.co.uk (Upon my return to England at Christmas)

Re: Ada & IBM

[Jerry Callen]

In article <20600018@inmet> ryer@inmet.inmet.com writes:
>
>Last I heard, Ada is not on the list of _acceptable_ languages for IBM's
>SAA (Systems Application Architecture?) applications.  (SAA is IBM's big
>new advance in portability and interoperability and a fundamental part
>of their strategy for computing in the 90's).  If a program
>is coded in Ada, it can't comply with SAA, regardless of any other
>compatibility or interfaces.  Has this changed?  It is easy to write
>a brochure, but where's the beef?
>

>Mike Ryer
>(personal comment, not endorsed by my employer, Intermetrics)

Hi, Mike! Actually, the "SAA Languages" are just the languages
that IBM is promising to keep _compatible_ on all of the SAA "platforms."
(Geez, I hate that psuedo-word.) Just because a language isn't supported
by IBM as an SAA language doesn't mean you can't _use_ the language on
an SAA system. In particular, I think it behooves IBM to come up with a 
standard set of Ada bindings to the various SAA subsystems (communications
and database, especially) that WOULD be portable across the SAA
platforms. After all, Ada is already totally portable, eh? :-)

-- Jerry Callen
   ...!{uunet, gould, maybe others}!encore!jcallen
   jcallen@encore.encore.com

   Do what you want to with my signature, but leave my employer alone!

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From lee@sq.sq.com (Liam R. E. Quin):
>>    [...] "Ada and IBM... Capability and Committment" states:
>>      IBM is committed to Ada.  Ada's support for modern software
>>      engineering concepts, its breadth of application, and its
>>      support for reuseable software components place it squarely
>>      in the forefront as a language of choice for both IBM's
>>      software engineers and for IBM's customers.
> 
> No doubt the simple elegance of Ada appealed to IBM

   Actually, it's rather surprising, since their background has
   largely consisted of primitive languages which offer little
   or no support for the software engineering process.  It's good
   to see IBM finally recognizing this major advance in software 
   engineering technology.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada vs. Posix -- the battle continues

[mjl]

In article <7053@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>> In particular, the
>> ordinary systems which most people will be seeing in front of them for the
>> next 5 - 15 years, UNIX systems and PCs, will not run Ada accepteably.
>
>
>   A prime example is Unix; the current POSIX effort aims to 
>   standardize 1960's technology, thus resulting in a "lowest
>   common denominator" which locks users into obsolescence.

Actually, both Unix and Ada are products of the 1970's.  The difference
is that Unix, being primarily of commercial interest, has been able to
evolve, whereas Ada, a government sponsored thing-a-ma-bob, has
stagnated.  It's a shrine to the ideas of 1975, both good and bad.  The
fact that Unix has evolved in ways incompatible with Ada says as at
least as much about Ada as it does about Unix.

I followed the development of Ada from its inception as Strawman, and
became increasingly more depressed as the work proceeded.  The good
concepts Ada embodies are overwhelmed by its complexity (see Hoare's
excellent discussion of this in his Turing Lecture -- all of his
comments still apply).

Ada is the PL/I of the 70's, unusable until the mid-80's; is it destined
to be the choke-collar of DoD software development in the 90's?

Mike Lutz
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

Re: Ada & Posix

[William Thomas Wolfe, 2847]

From mjl@cs.rit.edu:
> Actually, both Unix and Ada are products of the 1970's.  The difference
> is that Unix, being primarily of commercial interest, has been able to
> evolve, 

   Thus generating the need for the POSIX effort.  Ada, on the 
   other hand, standardized itself to start with.  Furthermore, 
   its definition was frozen for ten years precisely in order to
   provide vendors with the ability to amortize their investments
   over that period of time.  Ada has always had its portability,
   whereas Unix is just now struggling to achieve it.

   Now that Unix is finally standardizing, work is also in progress
   (in the IEEE 1003.5 committee) to develop a standardized Ada binding
   to the IEEE 1003.1 POSIX standard.  From AlsyNews, September 1989:

      Ada applications will have a major portability advantage
      over C applications because Ada's strong typing will assure
      that an application accesses only the services that are in
      the POSIX packages.  A C application might inadvertently mix
      portable POSIX services with non-portable services provided
      by the local operating system.

   A full IEEE ballot on the Ada binding to POSIX is expected by year-end.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & Posix

[William Thomas Wolfe, 2847]

From billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu:
>    Ada has always had its portability,
>    whereas Unix is just now struggling to achieve it.

   Consider also this quote from last Wednesday's Wall Street Journal:

      Currently, about 9% of the world's computers run Unix.
      It was feared that the computer industry's inability to
      agree on a single version of Unix would slow its spread.
      But because there is now a potential standard version of
      Unix, the operating system's popularity is expected to
      surge.  Analysts estimate that more than a quarter of the
      computer systems will run Unix by 1993.  "Having a clear
      common [standard] will encourage the perception that Unix
      is a mainstream product," said Eric Schmidt, vice president 
      of Sun Microsystems Inc.'s general systems group.

   Contrary to what some Usenetters seem to think, Unix is by no
   means universal; it is only recently discovering the need to
   impose the discipline of standardization, so that it might seek 
   more than its present single-digit level of market share.
 

   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada

[Andrew Koenig]

In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

>    Written by the designer of C++, whose definition of object-oriented
>    is "Object-oriented programming is programming using inheritance".

Where on earth did you pick up that notion?
-- 
				--Andrew Koenig
				  ark@europa.att.com

Re: Ada [and the object oriented metaphor]

[mjl]

In article <7115@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   The definition of "object-oriented" varies widely, but even if we
>   accept this definition, we need only obtain Classic Ada (or some 
>   equivalent preprocessing product) in order to use inheritance in
>   an Ada environment, pending more direct support in Ada 9X.

The mind boggles: Hoare's Turing Lecture concerns about the safety of
the world have now been compounded by an order of magnitude!  I'm a
proponent of the OO approach, but this instance is all too reminiscent
of the "bag on the side of a bag" system of design so eloquently
described in Kidder's "The Soul of a New Machine." Ada is already a
tarpit of complexity.  While the natural world evolves by selection,
Ada seems destined to "evolve" by accretion.

Mike Lutz

P.S.  I'm can hardly wait for AdaLog and CommonAda, preprocessors
providing all the "benefits" of Ada as well as the logic programming
model of PROLOG and the list processing capabilities of CommonLisp.
[1/2 :-)]
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

Re: Ada

[Mats Luthman]

In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

>    Written by the designer of C++, whose definition of object-oriented
>    is "Object-oriented programming is programming using inheritance".

As far as I recall Bjarne Stroustrup supports the widely accepted definition
of "Object oriented language":

  A language that supports:

*  Data abstraction (encapsulation)
*  Inheritance
*  Dynamic binding

I guess that people who claim that Ada is object oriented don't agree with
this definition, at least not with the third requirement, but saying what
I cited above is (and was probably meant to be) an insult to B.S. and his
intellectual capability.

Mats Luthman

Re: Ada

[William Thomas Wolfe, 2847]

From ark@alice.UUCP (Andrew Koenig):
> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>    Written by the designer of C++, whose definition of object-oriented
>>    is "Object-oriented programming is programming using inheritance".
> 
> Where on earth did you pick up that notion?

    From his article "What is Object-Oriented Programming", IEEE
    Software, May 1988... it's a direct quote.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: interesting statistic

[William Thomas Wolfe, 2847]

From rcd@ico.isc.com (Dick Dunn):
> I guess we can conclude that NTT maintained a commitment to Ada in spite of
> a five-year lack of production-quality compilers???

    Conclusion correct... they were apparently doing MIS applications 
    in which the quality of the object code was not very important.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Ada & IBM

[William Thomas Wolfe, 2847]

From rcd@ico.isc.com (Dick Dunn):
> What has IBM got for Ada?  How are they using it?

   Compilers, a comprehensive Ada Programming Support Environment, 
   interfaces to IMS/VS, DB2, SAA, and SQL, an Ada equivalent of 
   CICS (called Ada Interactive Services), and so on.  Further info
   can be obtained from the IBM Ada Help Desk (1-800-387-0262). 

   IBM's Systems Integration Division is doing Ada projects in 
   its Colorado, Maryland, Texas, Virginia, and New York locations,
   ranging from embedded and real-time systems to commercial systems.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Hoare, Ada, and safety/complexity

[John Goodenough]

There is a fairly widespread perception that Hoare's Turing Lecture represents
his complete opinion on Ada, as noted in a recent in article, Re: Ada [and the
object oriented metaphor] of 21 Nov 89 14:35:58 GMT mjl@prague.UUCP (Michael
Lutz):

>The mind boggles: Hoare's Turing Lecture concerns about the safety of
>the world have now been compounded by an order of magnitude!  ...

In 1987, Hoare wrote:

    ...an important goal in the design of a new programming language [is] that
    it should be an aid in specification, description, and design of programs
    as well as in the construction of reliable code.

    This was one of the main aims in the design of the language which was
    later given the name Ada.  As a result, the language incorporates many
    excellent structural features which have proved their value in many
    precursor languages such as Pascal and Pascal Plus.

    The combination of many complex features into a single language has led to
    an unfortunate delay in availability of production-quality
    implementations.  But the long wait is coming to an end, and one can now
    look forward to a rapid and widespread improvement in programming
    practice, both from those who use the language and from those who study
    its concepts and structures.

							     C. A. R. Hoare

    [in the Foreword to "Ada, Language and Methodology" by David A Watt, Brian
    A.  Wichmann, and William Findlay, Prentice-Hall, 1987.]

(Of course, the game of "proof by authority" is not all that interesting, but
if you're going to play it, ...)

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391
-- 
John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

Re: Ada

[Markku Sakkinen]

In article <10171@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
-In article <7115@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
-
->    Written by the designer of C++, whose definition of object-oriented
->    is "Object-oriented programming is programming using inheritance".
-
-Where on earth did you pick up that notion?

I would say that is the main theme of Stroustrup's paper from ECOOP'87
(What is "Object-Oriented Programming), a little simplified.
So, where on earth = in Paris (site of ECOOP'87) :-)
Obviously, it is hard to maintain that languages such as Ada and CLU
are not "object-oriented" in the least, unless one takes inheritance
as the single most important concept of OO.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland

Re: Ada

[Mats Luthman]

In article <7171@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From ark@alice.UUCP (Andrew Koenig):
>> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>>    Written by the designer of C++, whose definition of object-oriented
>>>    is "Object-oriented programming is programming using inheritance".
>> 
>> Where on earth did you pick up that notion?
>
>    From his article "What is Object-Oriented Programming", IEEE
>    Software, May 1988... it's a direct quote.
>
>
>    Bill Wolfe, wtwolfe@hubcap.clemson.edu


The article is 21 pages long, and is a thorough explanation of what
the author means by 'object oriented programming'. The trick of chosing
one sentence, ripped out of its context, is used again.

Mats Luthman











***

Re: Hoare, Ada, and safety/complexity

[Richard Pattis]

Indeed, Tony Hoare wrote the foreword quoted (the complete foreword is about
twice as long).  Here is the context:  Hoare is a series editor for Prentice-
Hall International, and he writes a foreword for most books in the series,
including the one written by Watt, Wichmann, and Findlay.

In my reading of the foreword, it shows a masterful double meaning in every
sentence.  It looks as if Hoare is praising Ada, but he is really praising
(1) the ideas behind Ada and (2) learning about Ada (without praising using
Ada). Every sentence has a wonderful spin on it.  I advise everyone to read
this foreword skeptically; you'll surely smile a bit.

The authors are much more positive in their praise of language (I vastly
prefer teaching it, compared to Pacsal or Modula-2 in my CS-1/CS-2 classes).
But I don't think Hoare's preface can in any way be construed as being
positive towards Ada, nor as anything contrary to his Turing lecture.

Rich Pattis

Re: interesting statistic

[Cay Horstmann]

In article <7172@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From rcd@ico.isc.com (Dick Dunn):
>> I guess we can conclude that NTT maintained a commitment to Ada in spite of
>> a five-year lack of production-quality compilers???
>
>    Conclusion correct... they were apparently doing MIS applications 
>    in which the quality of the object code was not very important.
>
>
>    Bill Wolfe, wtwolfe@hubcap.clemson.edu

I guess we therefore can conclude that Ada is perfectly suited for doing
MIS applications in which the quality of the object code is not very important.

If Ada has friends like Bill, does it need enemies?  :-)

Cay
> 

Re: interesting statistic

[William Thomas Wolfe, 2847]

From horstman@sjsumcs.sjsu.edu (Cay Horstmann):
>>> I guess we can conclude that NTT maintained a commitment to Ada in spite of
>>> a five-year lack of production-quality compilers???
>>
>>    Conclusion correct... they were apparently doing MIS applications 
>>    in which the quality of the object code was not very important.
% 
% I guess we therefore can conclude that Ada is perfectly suited for doing
% MIS applications in which the quality of the object code is not very 
% important.

    Quite correct.  Now that production-quality compilers are widely
    available, it is also perfectly suited for an extremely wide range
    of applications, and is being used accordingly.


    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: Ada & IBM

[Liam R. E. Quin]

[I wrote]
>> No doubt the simple elegance of Ada appealed to IBM
[Bill Wolf wrote]
>   Actually, it's rather surprising, since their background has
>   largely consisted of primitive languages which offer little
>   or no support for the software engineering process.  It's good
>   to see IBM finally recognizing this major advance in software 
>   engineering technology.

Uh, did I leave off the :-) signs?  I was not being serious. 

Let's not start religious Ada vs. <whatever> quarrels.
[mail me if you absolutely must, I'll try not to take EXCEPTION :-)].

Lee


-- 
Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!]
lee@sq.com (Whilst visiting Canada from England, until Christmas)
Software engineering is largely a philosophy, a state of mind.

Re: Ada vs. C++

[Paul S. R. Chisholm]

From pff@beach.cis.ufl.edu (Pablo Fernicola):
> In IEEE Software, Vol.5 Num. 3 page 26, we read
> 	"C++ has several advantages over Ada: ..."

In article <7115@hubcap.clemson.edu>,
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
(William Thomas Wolfe, 2847) writes:
>    But unfortunately seems to be missing fundamental features
>    such as exceptions, generics, and concurrency...

Exceptions:  Dr. Stroustrup just made a proposal for doing exceptions
in C++.  It looks pretty good.

Generics:  Dr. Stroustrup made a proposal sometime last year on
parametarized types.  His exception handling paper uses the same
syntax, so presumably he's reasonably comfortable with it.

Concurrency:  Most of the time, C++ programs (and programmers) should
use the facilities of the target platform.  Dr. Stroustrup has provided
support for "tasks" in both "C with classes" and C++; the AT&T C++
Language System comes with a Task class.  That's as close to standard
as C++ comes these days.  No, there's no direct support in the language
(special syntax, etc.) for supporting concurrency, for the same reason
there's no direct support for I/O:  it's better done in a library.

To summarize, C++ has the same support for exceptions and generics that
Ada has for inheritance.  (The Ada preprocessor you mention is a red
herring for DOD contractors, unless you propose they submit the
*output* of the preprocessor.)

>    Bill Wolfe, wtwolfe@hubcap.clemson.edu

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

Re: Ada & IBM

[Ken Ritchie]

Recapping: IBM has elected to pursue Ada, surprising some folks(?) :-)

C'mon folks... doesn't anybody KNOW about IBM?
This had to be a MARKET DRIVEN decision, since
IBM (by their own assertion) IS MARKET DRIVEN!
The attractiveness of the smiling Countess ;-)
(dear Ada) can be only a secondary persuasion.

There's going to be a *BOOM* in Ada-based BUSINESS (i.e. $$) and
IBM's obvious intention is to be right where the action is!! 8-)

DISCLAIMER: I'm opinionated, who isn't?  
_______________________________________________________________________________

Ken Ritchie (d/b/a KCR)			Usenet:	...!uunet!netxcom!netxdev!kcr
c/o NetExpress Communications, Inc.	FAX/office:	USA (703) 749-2375

ADA compilers

[John Ostlund]

Anyone know of any ADA compilers for a PC and/or SUN workstations???

(any ADA interpreters available?)

Please reply to: OSTLUND@SRC.Honeywell.com

      Thanks in advance, John.

ADA COMPILERS

[douglassalter@ajpo.sei.cmu.edu,]

Could you please sent a list of validated ADA compilers to
 dsalter@BCGUNT.AF.MIL - DDN address 26.7.0.13. We are especially interested
any WANG ADA compilers.

Ada Compilers.

[David Leslie Garrard]

Iam looking for an ada compiler that runs under unix and is distributed
under a GNU type distribution.

DLG

ADA Compilers

[A REILLY]

I'm currently a student at Portsmouth University, studying Computer
Science and I'm interested in obtaining a decent ADA 95 Compiler.  If
anyone knows where I can get one (Cheap) please let me know.

Cheers Andy :-)

Re: ADA Compilers

[Jon S Anthony]

In article <4q24t4$fdn@newsbf02.news.aol.com> areilly@aol.com (A REILLY) writes:

> I'm currently a student at Portsmouth University, studying Computer
> Science and I'm interested in obtaining a decent ADA 95 Compiler.  If
> anyone knows where I can get one (Cheap) please let me know.

ftp cs.nyu.edu, in /pub/gnat

There you will find the following (among other stuff)

emacs-ada-mode-2.12.tar.gz*
emx09b-gnat-os2-bin-disk1.zip*
emx09b-gnat-os2-bin-disk2.zip*
ez2load/
features*
gdb/
gnat-3.01-bin-m68k-next-nextstep3.tar.gz*
gnat-3.01-linuxaout.README
gnat-3.01-linuxaout.tar.gz*
gnat-3.01-mips-dec-ultrix4.3-bin.tar.gz*
gnat-3.03-hppa-bin.tar.gz*
gnat-3.03-i386-next-nextstep3-bin.tar.gz*
gnat-3.03-unknown-i386-solaris2.4-README
gnat-3.03-unknown-i386-solaris2.4-bin.tar.gz*
gnat-3.04-i386-unknown-netbsd1.1-README*
gnat-3.04-i386-unknown-netbsd1.1.tar.gz*
gnat-3.04-i486-linux-elf-bin.tar.gz*
gnat-3.04-src-netbsd.diff.gz*
gnat-3.05-alpha-dec-osf3.2-bin.tar.gz*
gnat-3.05-i486-linux-elf-bin.tar.gz*
gnat-3.05-mips-sgi-irix5.3-bin.tar.gz*
gnat-3.05-os2-bin-disk1.zip*
gnat-3.05-os2-bin-disk2.zip*
gnat-3.05-os2-bin-disk3.zip*
gnat-3.05-rs6000-ibm-aix3.2-bin.tar.gz*
gnat-3.05-sparc-sun-solaris2.4-bin.tar.gz*
gnat-3.05-sparc-sun-sunos4.1.3-bin.tar.gz*
gnat-3.05-src-update.tar.gz*
gnat-3.05-src.tar.gz*
gnat-dos-readme
gnat-windows95-readme*
win95/

> 
> Cheers Andy :-)

Cheers!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Ada Compilers

[Nathan A. Barclay]

The project I'm working on at work is looking into switching from Ada 83 to
Ada 95, and I've been trying to get an idea of how the different Ada 95
compilers compare.  Specifically, the compilers we're considering are GNAT
with Ada Core Technologies' support, Aonix's ObjectAda, Green Hills
Software's Ada compiler, and MAYBE Rational Apex Ada (although it's probably
too expensive).  If anyone has any thoughts on how the compilers compare (or
on related questions, e.g. something they especially like or dislike about
one of them), I'd love to hear them.  We're looking specifically at Sun
Sparc/Solaris systems, but thoughts stemming from other platforms might be
useful too, if not to me then maybe to others.

Re: Ada Compilers

[bklungle]

I can give you our current experiences. Yours may vary based on usage.

We are using Verdix Ada 83 on AIX (RS6k), Green Hills Ada 83 on AIX (RS6k)
cross targeted to the Rad-Hard RS6k with VxWorks, Green Hills Ada 83 on
Sparc/Solaris self targeted for debugging prior to using the cross compiler,
GNAT Ada95 on Dual P6/180 running Linux, GNAT Ada95 on IRIX 5.3 SGI Indigo2.
Another company we subcontract to is using Rational Apex C++ on SGI Indigo2.
Overall, the majority of the programmers prefer the GNAT Ada 95. If you go
this route, definitely grab ACT support. They have some excellent extended
tools and VERY knowledgable people who are willing to help, not like some
who take your money and return nothing.
To date, Rational Apex C++ is having trouble for as yet unknown reasons.
Again, experiences vary.

cheers...bob

Nathan A. Barclay wrote in message ...
>
>
>The project I'm working on at work is looking into switching from Ada 83 to
>Ada 95, and I've been trying to get an idea of how the different Ada 95
>compilers compare.  Specifically, the compilers we're considering are GNAT
>with Ada Core Technologies' support, Aonix's ObjectAda, Green Hills
>Software's Ada compiler, and MAYBE Rational Apex Ada (although it's
probably
>too expensive).  If anyone has any thoughts on how the compilers compare
(or
>on related questions, e.g. something they especially like or dislike about
>one of them), I'd love to hear them.  We're looking specifically at Sun
>Sparc/Solaris systems, but thoughts stemming from other platforms might be
>useful too, if not to me then maybe to others.
>
>
>

Ada Compilers

[David Rasmussen]

What is the best free Ada compiler available?

I know that question is probably silly and will get me redirected to the 
faq. Still, I would like to hear _people's_ opinion, instead of the 
usual "we can't say what's best, that's relative".

More importantly, what do the free compilers lack in contrast to the 
commercial ones?

Also, how portable is typical Ada, and how good is code generation 
compared to C++ on the same platform (typically)?

/David

Re: Ada Compilers

[Marin David Condic]

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
in message news:3CE2AF22.2060208@gmx.spam.egg.sausage.and.spam.net...
> What is the best free Ada compiler available?

AFAIK, there are only two that are free. ObjectAda (which comes in a limited
version as a kind of "trial" size) and GNAT. Of the two, GNAT is generally
used more because it is not limited - its the full-up production quality
compiler.

There are also some that could be considered "cheap" (money-wise). RR
Software and ObjectAda have versions that are priced within the reach of an
average hobbyist.

>
> I know that question is probably silly and will get me redirected to the
> faq.

See: http://www.adapower.com/ for more info. (Including the FAQ)

Look under "Links" for Ada compilers and vendors. Also under Resources.


Still, I would like to hear _people's_ opinion, instead of the
> usual "we can't say what's best, that's relative".
>
For the record: "we can't say what's best, that's relative". :-) It truly
is, because it depends on what you want to do with it. If you want a
recommendation about what is "best" for a hobbyist with a PC and Windows who
just wants to learn Ada for general purpose software development, I'd say
that GNAT is probably best. You can't beat its price/performance ratio! But
the issue can become immediately sticky the moment you start introducing
other variables - type of application, host/target hardware,
embedded/realtime, required level of support, etc.


> More importantly, what do the free compilers lack in contrast to the
> commercial ones?
>
The free compilers generally won't supply you with any support for the money
you aren't paying. However, if you need support, there are ways to get it -
you just have to open up your wallet. You also won't have the kinds of
selection of targets and such that for-money compilers typically can
provide. You also won't get all of the available tools or the
latest/greatest versions of things either. You get what you pay for - should
be pretty obvious, eh?


> Also, how portable is typical Ada, and how good is code generation
> compared to C++ on the same platform (typically)?
>
Ada is extremely portable. You have to know something about how to make code
portable since you can always hook yourself into platform dependencies no
matter what language you're given. Ada is generally more portable than C++
because compilers have to run a validation suite & AFAIK, most C++ compilers
aren't being validated against the latest standard. (Lots of known variance
between the different compilers and the standard.) I have ported large apps
a number of times between Alpha/VMS, Sun/Unix and PC/Windows & had
surprisingly few problems - often requiring nothing more than a recompile.
But then again, I *knew* I'd have to port so I wasn't hooked into platform
dependencies - or had them isolated where the problems would be minimized.

Quality of code generation? You can't compare this. Its been discussed here
many times. The *language* doesn't determine the quality of code generation.
The *implementation* does. Some compilers are better than others - and
that's all you can hope to compare. (For example: "How good is this version
of the GNAT Ada compiler on a PC versus that version of the MSVC++ compiler
for the PC given this specific collection of algorithms/code?")

That said, there is nothing inherent in Ada that would make it less
efficient than C/C++. Many implementations of Ada generate code that is as
good or better than many implementations of C/C++ for equivalent programs.
So don't worry that Ada is going to somehow or other be "slow". You have to
pick a quality compiler that produces good code for the types of algorithms
you usually write and you have to know the language/implementation well so
that you can get the most out of it.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Ada Compilers

[Jacob Sparre Andersen]

David Rasmussen wrote:

> What is the best free Ada compiler available?

I don't know, but GCC appears to be the most popular one.

> More importantly, what do the free compilers lack in contrast to the
> commercial ones?

Cost. ;-)

> Also, how portable is typical Ada,

Very portable. When I make data processing programs they can
usually work on OS/2 and at least a few different Unix'es
without any changes. For big projects (>100,000 lines of
code) it is my impression that less than 0.1% of the code
lines will have to be changed.

> and how good is code generation
> compared to C++ on the same platform (typically)?

It is kind of hard to say, but on thing to be aware of right
now is that GCC/Ada still primarily is distributed as GCC
2.8, whereas GCC/C++ primarily is distributed as GCC 3.0,
i.e. with a newer and supposedly better code generator. Once
GCC/Ada is also distributed based on the official GNU CVS
this difference will disappear.

Jacob
-- 
Growing older is compulsory. Growing up isn't.

Re: Ada Compilers

[Marin David Condic]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:3CE2C8FD.CDD0E75B@nbi.dk...
> David Rasmussen wrote:
>
> > More importantly, what do the free compilers lack in contrast to the
> > commercial ones?
>
> Cost. ;-)
>

It occurs to me that the OP may have been wondering if the free compilers
don't implement as much of the language as do the commercial ones. If that's
the question, then it is important to observe that GNAT does implement the
whole language. ObjectAda implements the full language as well, but I have
not examined the free version to know if part of the limitations are lack of
some features. I'd suspect the limits are not with respect to supported
language features.

Otherwise, its going to come down to add-on tools, support, updates, etc.
What do you want/need beyond the ability to translate Ada source into
executable programs?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Ada Compilers

[Pascal Obry]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> David Rasmussen wrote:
> 
> > What is the best free Ada compiler available?
> 
> I don't know, but GCC appears to be the most popular one.

Well the Ada compiler part of GCC is named GNAT (GNU/Ada).

> > More importantly, what do the free compilers lack in contrast to the
> > commercial ones?
> 
> Cost. ;-)

Note that there is only one free (speech) Ada compiler, and it is the single
Ada compiler to implement all Ada annexes.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada Compilers

[Kai Schuelke]

----- Original Message -----
From: "Pascal Obry" <p.obry@wanadoo.fr>
Newsgroups: comp.lang.ada
Sent: Wednesday, May 15, 2002 11:38 PM
Subject: Re: Ada Compilers


> Note that there is only one free (speech) Ada compiler, and it is the
single
> Ada compiler to implement all Ada annexes.

Hello,

could you please explain whats the difference to the Aonix compiler? Or
which annexes the other compilers didn't implement? I am just a beginner but
my first impression was that Aonix produced more "reliable" results. But
thats just a feeling.

Good night

Kai Schuelke

Re: Ada Compilers

[Florian Weimer]

David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> writes:

> More importantly, what do the free compilers lack in contrast to the
> commercial ones?

GNAT lacks unimplemented annexes in contrast to proprietary compilers?
(GNAT is a commercial compiler, too, so you probably mean something 
else.)

> Also, how portable is typical Ada, and how good is code generation
> compared to C++ on the same platform (typically)?

That's easy in the case of GNAT: identical for equivalent programs.
Both GNU compilers share the same code generator.

Re: Ada Compilers

[Steve Doiel]

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
in message news:3CE2AF22.2060208@gmx.spam.egg.sausage.and.spam.net...
> What is the best free Ada compiler available?

GNAT

> I know that question is probably silly and will get me redirected to the
> faq. Still, I would like to hear _people's_ opinion, instead of the
> usual "we can't say what's best, that's relative".
>
> More importantly, what do the free compilers lack in contrast to the
> commercial ones?

If you're just talking compiler, Gnat actually provides more than some of
the proprietary ones.

> Also, how portable is typical Ada, and how good is code generation
> compared to C++ on the same platform (typically)?

Portability: Excellent
Code generation: Very Good.  If you're comparing with free C++, Excellent.

>
> /David
>

Re: Ada Compilers

[Preben Randhol]

On Thu, 16 May 2002 00:35:35 +0200, Kai Schuelke wrote:
> could you please explain whats the difference to the Aonix compiler? Or
> which annexes the other compilers didn't implement? I am just a beginner but
> my first impression was that Aonix produced more "reliable" results. But
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why do you think that?

> thats just a feeling.

Preben

Re: Ada Compilers

[Preben Randhol]

On Wed, 15 May 2002 20:55:30 +0200, David Rasmussen wrote:
> What is the best free Ada compiler available?

GNAT

available for Linux, Solaris, Windows, MacOS (there is a port worked on
by individuals)

GNAT will also be part of GCC.

> More importantly, what do the free compilers lack in contrast to the 
> commercial ones?

Nothing.

> Also, how portable is typical Ada, and how good is code generation 
> compared to C++ on the same platform (typically)?

Ada code is much more portible and if you use the libraries GNAT
supplies for interacting with the IO etc.. a recompile should be all you
need to do from one system to another. 

What do you mean how good is code generation?

More info is here why you should choose Ada over say C++:

   http://www.adapower.com/what.html

Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Ada Compilers

[Preben Randhol]

On Thu, 16 May 2002 10:33:34 +0000 (UTC), Preben Randhol wrote:
> On Wed, 15 May 2002 20:55:30 +0200, David Rasmussen wrote:
>> What is the best free Ada compiler available?
> 
> GNAT
> 
> available for Linux, Solaris, Windows, MacOS (there is a port worked on
> by individuals)

and many other systems.
-- 
Preben Randhol ------------------- http://www.pvv.org/~randhol/ --
                 �For me, Ada95 puts back the joy in programming.�

Re: Ada Compilers

[Dmitry A. Kazakov]

On Thu, 16 May 2002 00:35:35 +0200, "Kai Schuelke"
<kai.schuelke@gmx.net> wrote:

>could you please explain whats the difference to the Aonix compiler? Or
>which annexes the other compilers didn't implement?

I believe it just limits the number of compilation units to 30.

>I am just a beginner but
>my first impression was that Aonix produced more "reliable" results. But
>thats just a feeling.

It does some things better and some worse than GNAT. It is nice to
have both, because in case of a compilation error messages from GNAT
and from Aonix nicely complement each other. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ada Compilers

[David Rasmussen]

Preben Randhol wrote:
> 
> What do you mean how good is code generation?
> 

I mean how good is the generated machine code on various CPU's (x86 for 
instance) with typical Ada compilers as compared with typical C++ compilers?

Re: Ada Compilers

[Preben Randhol]

On Thu, 16 May 2002 13:25:22 +0200, David Rasmussen wrote:
> Preben Randhol wrote:
>> 
>> What do you mean how good is code generation?
>> 
> 
> I mean how good is the generated machine code on various CPU's (x86 for 
> instance) with typical Ada compilers as compared with typical C++ compilers?
> 

Why? The important question is how good is the quality of the software
produced with Ada compared to C++.

Preben

Re: Ada Compilers

[Marin David Condic]

True, but misleading. GNAT and GNU C/C++ may all share the same back end &
hence produce similar code for similar input programs, but that in no way
says anything about how good the code is compared to some other compiler
that works for either Ada, C or C++. Its theoretically possible that the gcc
backend might generate really crappy code and hence Ada and C++ are equally
bad. What does that tell you about the relative efficiency of Ada or C++?

This is why its totally useless to ask the question "How does Ada compare
against C++ for efficiency...?" The best we can answer is that the Ada
standard doesn't impose anything that is inherently inefficient for the
semantic content delivered and the rest is a matter of comparing one
compiler against another. There are efficient implementations of both Ada
and C++. There are also bad implementations of both languages. We *really*
need to educate developers (who *should* know this by the time they leave
college!) that languages aren't "slow" - only implementations are.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Florian Weimer" <fw@deneb.enyo.de> wrote in message
news:878z6kq4rr.fsf@deneb.enyo.de...
>
> That's easy in the case of GNAT: identical for equivalent programs.
> Both GNU compilers share the same code generator.

Re: Ada Compilers

[David Rasmussen]

Preben Randhol wrote:
> On Thu, 16 May 2002 13:25:22 +0200, David Rasmussen wrote:
> 
>>Preben Randhol wrote:
>>
>>>What do you mean how good is code generation?
>>>
>>
>>I mean how good is the generated machine code on various CPU's (x86 for 
>>instance) with typical Ada compilers as compared with typical C++ compilers?
>>
> 
> 
> Why? The important question is how good is the quality of the software
> produced with Ada compared to C++.
> 
> Preben

No. For some applications, timewise performance is critical, and when 
you have chosen the design and improved the algorthms used as much as 
possible, you still want the fastest code possible. The quality of the 
software is of course paramount always, but if runtime performance is 
also an all-important criterion (but portability etc. also is, so you 
can't use assembler), it will be important to you how good the generated 
code is. It is for me, even if safety, correctness etc. is equally 
important.

/David

Re: Ada Compilers

[Marin David Condic]

Not entirely fair. It is perfectly fair to ask about the quality of code
generation for specific language implementations. Efficiency is a reasonable
concern - sometimes a *critical* concern such as when dealing with hard
realtime constraints.

The best answer is that there are very good, highly optimizing Ada compilers
that can produce code every bit as tight as the best C/C++ compilers for
similar programs. The caveat is that you can *only* talk about specific
compilers and targets - not about the language in general. For example, (as
observed elsewhere) the GNAT compiler and the GCC C/C++ compilers share the
same back end & generate pretty much identical code for identical programs
of different languages. Is GCC a "good" compiler for the x86 PC? Most people
think so. Hence, GNAT is going to be just as efficient - sometimes even
moreso - than C or C++ going through the GCC compiler. Are there *better*
compilers out there than GCC/GNAT? Maybe - for a given platform - and for
given algorithms/applications - and some of them will compile Ada while
other compile C or C++ or Fortran or who knows what. If efficiency is a
critical concern, the only hope is to conduct timing studies comparing
different implementations for the problems at hand. If efficiency is just a
casual concern, then rest asured that there are implementations of Ada that
are Good Enough.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"Preben Randhol" <randhol+abuse@pvv.org> wrote in message
news:slrnae79li.oe.randhol+abuse@kiuk0156.chembio.ntnu.no...
> On Thu, 16 May 2002 13:25:22 +0200, David Rasmussen wrote:
> >
> > I mean how good is the generated machine code on various CPU's (x86 for
> > instance) with typical Ada compilers as compared with typical C++
compilers?
> >
>
> Why? The important question is how good is the quality of the software
> produced with Ada compared to C++.
>

Re: Ada Compilers

[Steve Doiel]

"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
in message news:3CE3B32D.9080309@gmx.spam.egg.sausage.and.spam.net...
[snip]
> For some applications, timewise performance is critical, and when
> you have chosen the design and improved the algorthms used as much as
> possible, you still want the fastest code possible. The quality of the
> software is of course paramount always, but if runtime performance is
> also an all-important criterion (but portability etc. also is, so you
> can't use assembler), it will be important to you how good the generated
> code is. It is for me, even if safety, correctness etc. is equally
> important.

I believe you will find that the performance of Ada matches or exceeds the
performance of C++ if you turn off runtime checks.  Since C++ does not have
these checks there is no compartive disadvantage to turning off the checks.
There is however the advantage that you can turn on the checks during
testing.  In many cases performance cost of runtime checks are low and they
are left enabled for delivered software.

> /David
>

Re: Ada Compilers

[Martin Dowie]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:jg17eu40v2r1vbnep19bd9i97e4qg5cfco@4ax.com...
> On Thu, 16 May 2002 00:35:35 +0200, "Kai Schuelke"
> <kai.schuelke@gmx.net> wrote:
>
> >could you please explain whats the difference to the Aonix compiler? Or
> >which annexes the other compilers didn't implement?
>
> I believe it just limits the number of compilation units to 30.

v7.2.1 SE is:

<= 35 units
<= 20 tasks
<= 2000 lines per 'compilation' (I think they actually mean compilation
unit)
<= 550 lines per 'Java compilation'

non-commercial use only, not validated.

Re: Ada Compilers

[David Rasmussen]

Steve Doiel wrote:
> "David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
> in message news:3CE3B32D.9080309@gmx.spam.egg.sausage.and.spam.net...
> [snip]
> 
>>For some applications, timewise performance is critical, and when
>>you have chosen the design and improved the algorthms used as much as
>>possible, you still want the fastest code possible. The quality of the
>>software is of course paramount always, but if runtime performance is
>>also an all-important criterion (but portability etc. also is, so you
>>can't use assembler), it will be important to you how good the generated
>>code is. It is for me, even if safety, correctness etc. is equally
>>important.
> 
> 
> I believe you will find that the performance of Ada matches or exceeds the
> performance of C++ if you turn off runtime checks.  Since C++ does not have
> these checks there is no compartive disadvantage to turning off the checks.
> There is however the advantage that you can turn on the checks during
> testing.  In many cases performance cost of runtime checks are low and they
> are left enabled for delivered software.
> 

Cool. That was what I was looking for.

/David

Re: Ada Compilers

[Fraser Wilson]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> It is kind of hard to say, but on thing to be aware of right
> now is that GCC/Ada still primarily is distributed as GCC
> 2.8, whereas GCC/C++ primarily is distributed as GCC 3.0,
> i.e. with a newer and supposedly better code generator.

Ah, timing is everything.  Apparently GCC 3.1 has just been released
(http://gcc.gnu.org/gcc-3.1/), and GNAT is one of the official front
ends: http://gcc.gnu.org/frontends.html

I guess it contains GNAT 3.14p, but it's a bit hard to tell from the
web page.

Fraser.

Re: Ada Compilers

[Ted Dennison]

"Kai Schuelke" <kai.schuelke@gmx.net> wrote in message news:<3ce2e29f.0@news.unibw-muenchen.de>...
> ----- Original Message -----
> From: "Pascal Obry" <p.obry@wanadoo.fr>
> Newsgroups: comp.lang.ada
> Sent: Wednesday, May 15, 2002 11:38 PM
> Subject: Re: Ada Compilers
> 
> 
> > Note that there is only one free (speech) Ada compiler, and it is the
>  single
> > Ada compiler to implement all Ada annexes.

> could you please explain whats the difference to the Aonix compiler? Or
> which annexes the other compilers didn't implement? I am just a beginner but
> my first impression was that Aonix produced more "reliable" results. But
> thats just a feeling.

Well, I certianly can't explain why you'd think its results are more
"reliable", unless this is some new meaning to the word of which I am
unaccustomed. :-)

The free (no cost) downloadable Aonix compiler doesn't support the
distributed system annex. There might be some more annexes it doesn't
have either, but nothing that would impair a beginner's ability to
program on Windows. It main drawback is that it is crippleware. Once
your program gets past a certian size, the compiler will refuse to
compile it. If you are just playing around with little programs, you
aren't likely to hit that limit though. If you do, you can fix that by
going out and purchasing the full version, which I understand is not
too much more expensive than VisualC++. Not a bad deal at all really.

The Gnu Ada compiler is free in terms of freedom; it, and thus its
users, are not in thrall to any one vendor or person. (See
http://www.gnu.org/philosophy/free-sw.html for more about what "Free
Software" is all about). It is not crippled in any real way, and I
believe implements *all* the annexes. Its main drawback for some is
that its IDE doesn't resemble the VisualC++ IDE, which a lot of newbie
programmers get lost without. If you are comfortable (or want to learn
to become comfortable) with Emacs, then this is probably the free
compiler for you. Apparently a VC++ style IDE is on the way too.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Ada Compilers

[Florian Weimer]

newsfraser@blancolioni.org (Fraser Wilson) writes:

[GCC 3.1]

> I guess it contains GNAT 3.14p,

No, it comes with a different version of the front end and the GNAT
tools.  There are quite a few additional features, AFAIK.

Re: Ada Compilers

[Pascal Obry]

"Kai Schuelke" <kai.schuelke@gmx.net> writes:

> > Note that there is only one free (speech) Ada compiler, and it is the
> single
> > Ada compiler to implement all Ada annexes.
> 
> Hello,
> 
> could you please explain whats the difference to the Aonix compiler? Or

First ObjectAda has a free (beer) version but it is not a free (speech)
compiler. You can't access ObjectAda sources.

> which annexes the other compilers didn't implement? I am just a beginner but

For example Annexe E, but there is others. GNAT implements all of them. Check
Aonix web site for the list of annexes they implement.

> my first impression was that Aonix produced more "reliable" results. But
> thats just a feeling.

This is just feeling I would say. I think that all compilers have their set of
problems.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada Compilers

[Pascal Obry]

Preben Randhol <randhol+abuse@pvv.org> writes:

> On Wed, 15 May 2002 20:55:30 +0200, David Rasmussen wrote:
> > What is the best free Ada compiler available?
> 
> GNAT
> 
> available for Linux, Solaris, Windows, MacOS (there is a port worked on
> by individuals)
> 
> GNAT will also be part of GCC.
       ^^^^^^^^^^^^
       is 

GCC 3.1 has been released yesterday :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada Compilers

[Kai Schuelke]

Hello,

what made me feel that Aonix is more "standard" was a combination of some
minor experiences we made at our Ada school and what the teachers said about
Aonix vs. Gnat (we used both). I can use the full license of Aonix, so that
I didn't see it's limitations.

What I really like about Aonix is the IDE (esp. the GUI-Builder) but thats
not really a compiler issue, but I have to admit that the Gnat error
messages were more helpful than the Aonix ones.

My feeling was intended to be a comment form a beginners point of view, but
no conclusion after years of experience.

ReadU

Kai Schuelke

Re: Ada Compilers

[Preben Randhol]

On Thu, 16 May 2002 15:25:01 +0200, David Rasmussen wrote:
> 
> No. For some applications, timewise performance is critical, and when 
> you have chosen the design and improved the algorthms used as much as 
> possible, you still want the fastest code possible. The quality of the 
> software is of course paramount always, but if runtime performance is 
> also an all-important criterion (but portability etc. also is, so you 
> can't use assembler), it will be important to you how good the generated 
> code is. It is for me, even if safety, correctness etc. is equally 
> important.

I agree with you. The reason I commented your question was that a lot of
people asking this question, but are not reflected as you seem to be.
People believe that the speed of the application is the most important
factor. This is generally not the case at all. At least when making
user applications. The user will loose far more time from program
crashes than that a program uses 2ms more to open a dialog.

Preben
-- 

Re: Ada Compilers

[Robert Dewar]

"Kai Schuelke" <kai.schuelke@gmx.net> wrote in message news:<3ce3ff73.0@news.unibw-muenchen.de>...

> what made me feel that Aonix is more "standard" was a
> combination of some minor experiences we made at our Ada > school

At this stage all the Ada 95 compilers that are available
are sufficiently conformant to the standard that it is
VERY unlikely that beginning students would run into any
discrepancies in any compiler, so these "minor experiences"
were probably misinterpreted.

Re: Ada Compilers

[Robert Dewar]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0205160706.52667440@posting.google.com>...
> If you are comfortable (or want to learn
> to become comfortable) with Emacs, then this is probably 
> the free compiler for you. Apparently a VC++ style IDE is 
> on the way too.

I think that Ted is giving dubious advice here. I would not
advise a beginner to plunge into EMACS. Instead the obvious
IDE to use is AdaGIDE which is specifically intended for
use by beginners learning Ada (but is sufficiently powerful
to support large projects).

Re: Ada Compilers

[Robert Dewar]

dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0205160706.52667440@posting.google.com>...
> Apparently a VC++ style IDE is on the way too.

Not sure what Ted is talking about here. If you are talking
about the GNAT Programming System (GPS), please be assured that
copying Microsoft was *not* a design criterion :-)

Re: Ada Compilers

[Preben Randhol]

On Thu, 16 May 2002 09:30:09 -0400, Marin David Condic wrote:
> Not entirely fair. It is perfectly fair to ask about the quality of code
> generation for specific language implementations. Efficiency is a reasonable
> concern - sometimes a *critical* concern such as when dealing with hard
> realtime constraints.

Yes, read my followup that explains why I asked.

Preben

Re: Ada Compilers

[Ted Dennison]

dewar@gnat.com (Robert Dewar) wrote in message news:<5ee5b646.0205161722.18eacc4b@posting.google.com>...
> dennison@telepath.com (Ted Dennison) wrote in message news:<4519e058.0205160706.52667440@posting.google.com>...
> > If you are comfortable (or want to learn
> > to become comfortable) with Emacs, then this is probably 
> > the free compiler for you. Apparently a VC++ style IDE is 
> > on the way too.
> 
> I think that Ted is giving dubious advice here. I would not
> advise a beginner to plunge into EMACS. Instead the obvious

Two things here:

1) I was advising nothing of the sort, which should have been quite
clear from the text you quoted. I was only giving an option
conditioned on whether the poster wants to use Emacs or not. There is
no text in my message on whether that's advisable or not. There's a
good reason for that, which is...

2) The poster never claimed to be a beginner with programming in
general, just with Ada. You could be right when you assume the former,
but that information was not presented for our consideration.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html (down)

Re: Ada Compilers

[Ted Dennison]

David Rasmussen <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote in message news:<3CE3B32D.9080309@gmx.spam.egg.sausage.and.spam.net>...
> No. For some applications, timewise performance is critical, and when 
> you have chosen the design and improved the algorthms used as much as 
> possible, you still want the fastest code possible. The quality of the 
> software is of course paramount always, but if runtime performance is 
> also an all-important criterion (but portability etc. also is, so you 
> can't use assembler), it will be important to you how good the generated 
> code is. It is for me, even if safety, correctness etc. is equally 
> important.


One thing I should mention here is that the Aonix compiler has *no*
compiler optimization options. Gnat and GCC have oodles of them. When
I asked Aonix about this, I was told that they do some optimization
(eg: peephole -type stuff) by default. But if you are into tweeking
optimization options on your compiler, I think you will be far happier
with Gnat.

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Ada Compilers

[Ted Dennison]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uvg9ot481.fsf@wanadoo.fr>...
> Preben Randhol <randhol+abuse@pvv.org> writes:
> 
> GCC 3.1 has been released yesterday :)

Cool! Forget Morrowind, I know what I'll be playing with tonight. :-)

I forget...do we have a good official place to put precompiled binaries?

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Ada Compilers

[Pascal Obry]

dennison@telepath.com (Ted Dennison) writes:

> I forget...do we have a good official place to put precompiled binaries?

What about AdaPower (http://www.adapower.com/) ? We already have pages for
Linux and Machintosh, what about a new section about GNAT 5.0 binaries ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada Compilers

[Preben Randhol]

On 17 May 2002 08:11:53 -0700, Ted Dennison wrote:
> Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<uvg9ot481.fsf@wanadoo.fr>...
>> Preben Randhol <randhol+abuse@pvv.org> writes:
>> 
>> GCC 3.1 has been released yesterday :)

Oh, I didn't say this. I didn't know this at all.

Preben

Re: Ada Compilers

[David Rasmussen]

Marin David Condic wrote:
> True, but misleading. GNAT and GNU C/C++ may all share the same back end &
> hence produce similar code for similar input programs, but that in no way
> says anything about how good the code is compared to some other compiler
> that works for either Ada, C or C++. Its theoretically possible that the gcc
> backend might generate really crappy code and hence Ada and C++ are equally
> bad. What does that tell you about the relative efficiency of Ada or C++?
> 
> This is why its totally useless to ask the question "How does Ada compare
> against C++ for efficiency...?" The best we can answer is that the Ada
> standard doesn't impose anything that is inherently inefficient for the
> semantic content delivered and the rest is a matter of comparing one
> compiler against another. There are efficient implementations of both Ada
> and C++. There are also bad implementations of both languages. We *really*
> need to educate developers (who *should* know this by the time they leave
> college!) that languages aren't "slow" - only implementations are.
> 

I know that, of course. My question was of a more pragmatic nature. Most 
languages (ML, Lisp, Java etc.) could have compilers that created as 
good code on a given platform (say x86), as the best C compilers for the 
same platform. But in real life, this is not at all the case. So my 
question was if, in practice, most Ada compilers generate code that is 
comparable to, say, C++ compilers. The question makes a lot of pragmatic 
sense.

/David

Re: Ada Compilers

[Simon Wright]

Pascal Obry <p.obry@wanadoo.fr> writes:

> What about AdaPower (http://www.adapower.com/) ? We already have pages for
> Linux and Machintosh, what about a new section about GNAT 5.0 binaries ?

I don't think 5.0 is right?, gnatls -v now says

  GNATLS 3.1 (20020501) Copyright 1997-2001 Free Software Foundation, Inc.

(don't know why the (c) date hasn't changed!)

I think the original 3.1 is so long ago that no one is going to care a
lot about the overloading. Or was it 3.01?!

Re: Ada Compilers

[Pascal Obry]

Simon Wright <simon@pushface.org> writes:

> Pascal Obry <p.obry@wanadoo.fr> writes:
> 
> > What about AdaPower (http://www.adapower.com/) ? We already have pages for
> > Linux and Machintosh, what about a new section about GNAT 5.0 binaries ?
> 
> I don't think 5.0 is right?, gnatls -v now says
> 
>   GNATLS 3.1 (20020501) Copyright 1997-2001 Free Software Foundation, Inc.

Right, I was confused, this is GNAT 3.1 on the FSF GCC tree.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Ada Compilers

[Jerry van Dijk]

dennison@telepath.com (Ted Dennison) writes:

> I forget...do we have a good official place to put precompiled binaries?

Yes, it's now part of the mingw project on sourceforge.

-- 
--  Jerry van Dijk   | email: jvandyk@attglobal.net
--  Leiden, Holland  | web:   users.ncrvnet.nl/gmvdijk

Re: Ada Compilers

[David Botton]

I would be happy to host any binaries. Please e-mail me directly when any
one is ready to upload and I will give them directions and make the page
available.

David Botton


"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:ur8kau4gc.fsf@wanadoo.fr...
>
> dennison@telepath.com (Ted Dennison) writes:
>
> > I forget...do we have a good official place to put precompiled binaries?
>
> What about AdaPower (http://www.adapower.com/) ? We already have pages for
> Linux and Machintosh, what about a new section about GNAT 5.0 binaries ?
>
> Pascal.

Re: Ada Compilers

[Jacob Sparre Andersen]

David Rasmussen wrote:

> So my
> question was if, in practice, most Ada compilers generate code that is
> comparable to, say, C++ compilers.

I haven't had time to compare the GCC 3.1 Ada and C++
compilers yet, but last time I compared the front-ends, the
Ada front-end was clearly better at optimising than the C++
one.

Jacob
-- 
Sk�ne Sj�lland Linux User Group - http://www.sslug.dk/
N�ste m�de: Foredragsaften p� Lunds Tekniske H�gskola.
Torsdag den 30. maj 2002 p�/i Lund, LTH, E:2116.

Re: Ada Compilers

[Marin David Condic]

Well, from a purely *practical* standpoint (realizing that we are talking
about existing implementations rather than either the language or any
particular compiler) we might say this: Most popular Ada implementations are
generating code that is pretty efficient in comparison to most other
compiled languages. You won't discover that your basic workstation/PC
application programmed in Ada is somehow bog-slow in comparison to the same
thing in some other language typically used for the same application.

Now a few caveats: If you truly have a time-critical application, you'd best
conduct a timing study with algorithms typical of the application at hand.
Compilers (even for the same language) can have a good deal of variance in
terms of the code they generate for different operations. Be sure that when
timing any Ada code, that you either *really* know what you're doing or that
you are working with the vendor to get the best possible optimization. (Its
easy to compile with all runtime checking in place and/or by using
constructs unwisely and discovering you have pretty slow code. Quite often
throwing a few compiler switches, or including a few pragmas or otherwise
tweaking things a bit, you get really nice code. But you need to know...)

There are some Ada implementations for some targets that are extremely
highly optimizing and will do a wonderful job of producing highly efficient
code. Remember that Ada was originally invented for embedded, real time
apps, so it is possible to find very efficient compilers. However, that
isn't saying there are highly efficient compilers for all platforms and
targets. It also isn't saying that they will be efficient for the algorithms
you intend to use. Compiler timing studies are *very* complex to get right.
(I've been through a couple of serious ones) But its the only way to get any
truly useful information.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com


"David Rasmussen" <david.rasmussen@gmx.spam.egg.sausage.and.spam.net> wrote
in message news:3CE58053.2020809@gmx.spam.egg.sausage.and.spam.net...
>
> I know that, of course. My question was of a more pragmatic nature. Most
> languages (ML, Lisp, Java etc.) could have compilers that created as
> good code on a given platform (say x86), as the best C compilers for the
> same platform. But in real life, this is not at all the case. So my
> question was if, in practice, most Ada compilers generate code that is
> comparable to, say, C++ compilers. The question makes a lot of pragmatic
> sense.
>

Re: Ada Compilers

[Ted Dennison]

David Humphris <dhumphris@aonix.co.uk> wrote in message news:<mailman.1021886521.4259.comp.lang.ada@ada.eu.org>...
> > One thing I should mention here is that the Aonix compiler has *no*
>  > compiler optimization options. Gnat and GCC have oodles of them. When
>  > I asked Aonix about this, I was told that they do some optimization
>  > (eg: peephole -type stuff) by default.
> 
> This used to be the case for ObjectAda for Windows however this has
> been rectified a couple of releases ago.  7.2.1 introduced the optimizer
> on the Windows platform.

I was unaware of that. Thanks for the clarification. Has the freely
downloadable "Special Edition" been so updated? That's the compiler we
were actually talking about.

-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Ada Compilers

[Ted Dennison]

Jerry van Dijk <jvandyk@attglobal.net> wrote in message news:<wk3cwpviph.fsf@attglobal.net>...
> dennison@telepath.com (Ted Dennison) writes:
> 
> > I forget...do we have a good official place to put precompiled binaries?
> 
> Yes, it's now part of the mingw project on sourceforge.

But that's only for Win32 precompiled binaries. Even if every platform
has its own official place for precompiled binaries, I'd think it
would be good for the Ada community to have one place where they are
all mirrored, no?

I know David has kindly offered his site up, so that's a good option.

To my mind, the most logical place would be on the GNUAda website
(http://www.gnuada.org/ ). Is that not the kind of thing it was
created for?


-- 
T.E.D.
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  http://www.telepath.com/dennison/Ted/TED.html

Re: Ada Compilers

[David Humphris]

 > > > One thing I should mention here is that the Aonix compiler has *no*
 > > > compiler optimization options. Gnat and GCC have oodles of them. When
 > > > I asked Aonix about this, I was told that they do some optimization
 > > > (eg: peephole -type stuff) by default.
 > >
 > > This used to be the case for ObjectAda for Windows however this has
 > > been rectified a couple of releases ago. 7.2.1 introduced the optimizer
 > > on the Windows platform.
 >
 > I was unaware of that. Thanks for the clarification. Has the freely
 > downloadable "Special Edition" been so updated? That's the compiler we
 > were actually talking about.

Yes they are available with 7.2.1 Special Edition on WIndows.

David Humphris.

Re: Ada Compilers

[Jerry van Dijk]

dennison@telepath.com (Ted Dennison) writes:

> > Yes, it's now part of the mingw project on sourceforge.
> 
> But that's only for Win32 precompiled binaries. Even if every platform
> has its own official place for precompiled binaries, I'd think it
> would be good for the Ada community to have one place where they are
> all mirrored, no?

The mingw project is the only place to get the properly patched native Win32
binaries. A link should be easy :-) As I said before, the real issue is the 
Win32 support (binding, tools) and things like the debugger and packaging.

-- 
--  Jerry van Dijk   | email: jvandyk@attglobal.net
--  Leiden, Holland  | web:   users.ncrvnet.nl/gmvdijk

Re: Ada Compilers

[Greg Bek]

As a compiler vendor I'd just like to echo MDC's comments.
Don't just use standard benchmarks, use your application or
portions of it for testing performance.  Benchmarks like
the PIWG's are not sufficiently sophisticated to properly
perform timing of null loops etc.

Ada compilers have many advantages over languages like C/C++
in that the compiler has greater visibility into the rest of
a user program.  An Ada compiler can automatically inline
code across multiple levels of subprogram call, C/C++ have
difficulty doing this as any called subprogram is usually
compiled into a different object module.  This means that
C/C++ must perform a call/return where the Ada code may
have the call/return (and associated prolog/epilog, stack
check) eliminated.

Our compiler (Rational Apex), performs this kind of inlining
as well as loop unrolling etc.  Another very useful technique
is "value propagation", this is where the compiler tracks the
range of values taken by an object.  Knowing the possible
range of values means that the compiler can eliminate 
constraint checks that are not needed.  This can have some
very disconcerting side affects for the unwary.

If the compiler determines that a section of code has no
side affects (ie: no exceptions can be raised), and that the
results of that section of code are not used, then it 
eliminates all of the code.   The PIWG henessey benchmark
is an example of code that suffers because of this. The
large matrix multiplication contained within the benchmark
is eliminated as the matracies are populated with small-ish
values, the compiler concludes that the range of the resulting
sum of products will never overflow.  It then discovers that
the resulting matrix is never used, so it throws out the entire 
matrix multiplication.  The surrounding timing loop is now 
timing a null operation.

Modern compilers are very good at producing optimized code
under most circumstances.

However there are some subtle issues with Ada that can 
prevent getting the best code possible.  The best example
of this is using controlled objects within your program.
Controlled types require the compiler to generate invisible
code that makes sure any objects are properly finalized when
a scope is exited.

When compiling a routine that uses a class wide type the
compiler may not know whether controlled types are used 
to extend the base type, so it must be pessimistic and 
generate finalization code that may never be called.

If you don't have controlled objects and your compiler has a 
mechanism for optimizing accordingly, then use that mechanism
(switch, library directive, configuration pragma).

As always your milage will vary.

Greg Bek
-------------------------------------------
Greg Bek  mailto:gab@rational.com
Product Manager, Rational Apex Family
Rational Software
-------------------------------------------

Re: Ada Compilers

[Robert Dewar]

gab@rational.com (Greg Bek) wrote in message news:<afb6d339.0205211331.30124c52@posting.google.com>...

> sum of products will never overflow.  It then discovers that
> the resulting matrix is never used, so it throws out the entire 
> matrix multiplication.  The surrounding timing loop is now 
> timing a null operation.

Right, in one case where GNAT was being compared with another
compiler on this test, both versions were testing the time for
this null loop, and because of an oddity, GNAT took longer. 
So we fixed it and then it took shorter. Wonderful, but nothing
at all to do with the intent of the test. The PIWG tests are
very poorly written from this point of view.

Re: Ada Compilers

[Marin David Condic]

"Greg Bek" <gab@rational.com> wrote in message
news:afb6d339.0205211331.30124c52@posting.google.com...
> As a compiler vendor I'd just like to echo MDC's comments.
> Don't just use standard benchmarks, use your application or
> portions of it for testing performance.  Benchmarks like
> the PIWG's are not sufficiently sophisticated to properly
> perform timing of null loops etc.
>
Thanks for the echo. Call me "Marin" - everyone else does. :-)

Artificial benchmarks may tell you something but it is *much* better to use
typical segments of your own apps to try to evaluate performance. Some apps
do lots of data motion, others do lots of comparisons, others do specific
kinds of math, etc. Any given compiler might, for example, generate *really*
tight code for linear equations, but generate slow code for data motion.
Vendors can't do everything, so they spend time optimizing particular
aspects of their products & you'll see as a result that perfectly fine
compilers will have considerable variance in what they come up with for
different applications.


> Ada compilers have many advantages over languages like C/C++
> in that the compiler has greater visibility into the rest of
> a user program.  An Ada compiler can automatically inline
> code across multiple levels of subprogram call, C/C++ have
> difficulty doing this as any called subprogram is usually
> compiled into a different object module.  This means that
> C/C++ must perform a call/return where the Ada code may
> have the call/return (and associated prolog/epilog, stack
> check) eliminated.
>
And of course, as every year goes by in the life of a compiler, more and
more optimizations are found. Every day, in every way, they're getting
better and better. :-) The Ada vendors certainly do have advantages over
some other more popular languages because of how well the language was
designed and the information content of the language being so high.


>
> Modern compilers are very good at producing optimized code
> under most circumstances.
>
We should remember to keep this in perspective too. When I was building
avionics systems, extremely aggressive optimization and really compact, fast
code were life-and-death issues for the projects. I use Ada now mostly for
PC-ish applications and performance is not nearly so critical. What matters
then are other sorts of creature comforts. (development tools, libraries,
etc.) The caveat being that when shopping for a compiler, you need to ask
about what is important for the intended project and not necessarily buy an
avionics-quality compiler just because you are obsessed with speed.

Of course, if someone can give me *everything* for *nothing* I'd be really
thrilled. But I won't hold my breath. :-)


> However there are some subtle issues with Ada that can
> prevent getting the best code possible.  The best example
> of this is using controlled objects within your program.
> Controlled types require the compiler to generate invisible
> code that makes sure any objects are properly finalized when
> a scope is exited.
>
If high performance is an issue for your apps, you need to *really*
understand the language or you can generate inefficient code and be
wondering why. You often have to experiment with alternate ways of
accomplishing the same thing to find the one that fools the compiler into
generating the code you want. I recall once dealing with initialization of
some records where expressing it one way caused the compiler to go off
making a bunch of subroutine calls, but doing it another way we got a single
move of a constant in memory. Know the language and experiment!


>
> As always your milage will vary.
>

Absolutely. And don't besmirch compiler X because it doesn't optimize your
code as nicely as compiler Y. It may optimize someone else's code better
and/or there is a good chance you don't know what you're talking about. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Ada Compilers

[John R. Strohm]

I'd be VERY interested in seeing a fairly detailed example on this
particular item.

Part of the GLOBAL thrust of what I'm doing is gearing myself up on Ada95,
with the idea in the back of my head of tackling some things that are
typically done in C/C++, and seeing if I can learn enough along the way to
replicate your results in a different domain area: 2x productivity, 1/4x
defect density.

Gotta do something to pass the time between job interviews and mailing out
resumes and such.

(The argument is something like this:  "Now, we all know that there really
aren't any silver bullets, right?  There really aren't any magic wands you
can wave, that will just like magic give you 2x productivity improvement and
1/4x defect density, right?  We all know that, don't we?  Well, what if
there was one?  Suppose there WAS such a wand, such a super secret magic
bullet, that really would let you tackle your current project with half as
many cars in the parking lot, that would let you write only 1/4 as many bug
reports and bug fix reports and retest reports.  If such a wand really did
exist, would you ignore it, throw it away, bury it in a landfill and post
armed guards 24/7 around it, or would you grab it and wave it for all you
were worth?")

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:acg7rd$15g$1@nh.pace.co.uk...
> If high performance is an issue for your apps, you need to *really*
> understand the language or you can generate inefficient code and be
> wondering why. You often have to experiment with alternate ways of
> accomplishing the same thing to find the one that fools the compiler into
> generating the code you want. I recall once dealing with initialization of
> some records where expressing it one way caused the compiler to go off
> making a bunch of subroutine calls, but doing it another way we got a
single
> move of a constant in memory. Know the language and experiment!

Re: Ada Compilers

[Marin David Condic]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:2AEB9D17A335FB6F.78506B6494B0AFF3.EE290620571FE224@lp.airnews.net...
> I'd be VERY interested in seeing a fairly detailed example on this
> particular item.
>
What item? The initialization thing? Its been a really long time so I don't
remember exactly what we did. We were using the XD-Ada compiler for the
Mil-Std-1750a. (Might also have been true of the MC680x0 target as well, but
I didn't test it on that path.) IIRC, we had a record type that was
initialized by default values. When you declared an object of that type, the
compiler generated subroutine calls for it to get it initialized. It was
causing speed problems, so we tinkered. Initializing it with an aggregate
instead (no default initial values for the type) got us down to the one-word
data move we wanted. Or maybe it was the other way around. :-) It *was* a
long time ago. But it illustrates that you can get very different code to
accomplish the same goal, so you really have to know your compiler, etc.


> Part of the GLOBAL thrust of what I'm doing is gearing myself up on Ada95,
> with the idea in the back of my head of tackling some things that are
> typically done in C/C++, and seeing if I can learn enough along the way to
> replicate your results in a different domain area: 2x productivity, 1/4x
> defect density.
>
You have to be real careful because there is always that all-important
caveat: YOUR MILEAGE MAY VARY!!! :-) In this particular realm, we had a very
specialized process and unlike most projects, we were frequently building
essentially the same thing over and over again. The kinds of errors we
encountered were really peculiar to the specific problem domain and wouldn't
necessarily apply across the board. Hence the productivity and defect rates
may not be anywhere near what someone else in another problem space would
realize. (You might even do better? Who knows?) Also, since we were
measuring a live process that was going on over maybe more than 10 years,
you didn't exactly have laboratory-grade isolation of just the language.
Other things were going on at the same time, so its hard to credit just Ada
for the improvements & have strong confidence that you could reproduce the
same result in another environment just by injecting a new language.


> Gotta do something to pass the time between job interviews and mailing out
> resumes and such.
>
I feel your pain. :-) Giving some thought to re-entering the fray once again
myself. Not a prospect I relish, but sometimes its the thing to do. Good
luck with it and I hope you find something where you can use & promote Ada.


> (The argument is something like this:  "Now, we all know that there really
> aren't any silver bullets, right?  There really aren't any magic wands you
> can wave, that will just like magic give you 2x productivity improvement
and
> 1/4x defect density, right?  We all know that, don't we?  Well, what if
> there was one?  Suppose there WAS such a wand, such a super secret magic
> bullet, that really would let you tackle your current project with half as
> many cars in the parking lot, that would let you write only 1/4 as many
bug
> reports and bug fix reports and retest reports.  If such a wand really did
> exist, would you ignore it, throw it away, bury it in a landfill and post
> armed guards 24/7 around it, or would you grab it and wave it for all you
> were worth?")
>

I understand and possibly agree - to a point. Its just that a lot more is
going to go into productivity and defects than just the language. Its that
bind of "All Other Things Being Equal" - which is almost never the case.
Sure, Ada (in the abstract sense) is better for building reliable software
quickly than is C. But what if C decides to cheat? If C gives you some huge
library of stuff that gets you 75% of the way out the door right now and
that library has been used/debugged extensively, and there is no equivalent
for Ada, will not C win? Or if the project is fairly short term and the
staff already knows C++ extensively and knows nothing about Ada, can Ada
win?

I believe Ada is better based on the evidence I've seen over the years. Its
just that the competition is seldom on an even playing field. The way around
that is for Ada to create its own playing field where the other languages
are at a disadvantage. We don't have to be "fair" or "nice" about it either,
do we? :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com

Re: Ada Compilers

[Ted Dennison]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<2AEB9D17A335FB6F.78506B6494B0AFF3.EE290620571FE224@lp.airnews.net>...
> (The argument is something like this:  "Now, we all know that there really
> aren't any silver bullets, right?  There really aren't any magic wands you
> can wave, that will just like magic give you 2x productivity improvement and
> 1/4x defect density, right?  We all know that, don't we?  Well, what if
> there was one?  Suppose there WAS such a wand, such a super secret magic

For the record, to qualify as Brooks' famous "Silver Bullet", you
would have to have something that would improve things by a factor of
10, not just 2 or 4. Ada provides a package that is pretty close to
what Brooks termed a "Brass Bullet" in his essay "No Silver Bullet,
Refired". He was talking about OO languages in general, but C++ and
Smalltalk were used as examples. I'd say Rational's numbers prove his
argument nicely.

Re: Ada Compilers

[Larry Kilgallen]

In article <2AEB9D17A335FB6F.78506B6494B0AFF3.EE290620571FE224@lp.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes:

> (The argument is something like this:  "Now, we all know that there really
> aren't any silver bullets, right?  There really aren't any magic wands you
> can wave, that will just like magic give you 2x productivity improvement and
> 1/4x defect density, right?

Depending on your present circumstance, there may be a silver bullet
that will give you those benefits.

But there is no silver bullet that will give _everyone_ those benefits
(irrespective of present circumstance).

ADA compilers

[Patty]

I am trying to find an ADA compiler for ADA83 for a Pentium/RedHat
Enterprise Linux 3 operating system platform, but have not been able to
locate one so far. Anyone know of one??

Re: ADA compilers

[Pascal Obry]

"Patty" <patricia.l.addiss@honeywell.com> writes:

> I am trying to find an ADA compiler for ADA83 for a Pentium/RedHat
> Enterprise Linux 3 operating system platform, but have not been able to
> locate one so far. Anyone know of one??

Why Ada83, are you porting an application ?

Have a look at GNAT. Part of GCC and commercial support available from
AdaCore. http://www.adacore.com. I'm sure there is some other compilers
for GNU/Linux I'll let other answer...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: ADA compilers

[Patty]

Yes, we are trying to port an existing application.  I have looked at
GNAT, but they only have ADA95.

Re: ADA compilers

[Dmitry A. Kazakov]

On 3 Jun 2005 12:12:01 -0700, Patty wrote:

> Yes, we are trying to port an existing application.

Egh, how to port Ada 83 to Ada 95 without Ada 95?

>  I have looked at GNAT, but they only have ADA95.

1. There should be no problem to port Ada 83 code to Ada 95.
Incompatibilities are rather minor.

2. AFAIK, GNAT has "-gnat83" switch for Ada 83 legacy code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: ADA compilers

[Jeff C]

Patty wrote:
> Yes, we are trying to port an existing application.  I have looked at
> GNAT, but they only have ADA95.
> 

The issues involved with an update from Ada 83 to Ada 95 are <<= any 
issues you will run into with simply porting code from one compiler/os 
to another.

If the existing code makes use of a lot of vendor specific packages and 
it does not encapsulate it well, this will be a bit of work.

In any case if I were doing a bid (and I've done lots of them) the port 
from Ada 83 to Ada 95 would probably not even how up in the last digit 
compared to any other issues associated with the port.


What can be a bit more difficult (situation I have been in for a long 
time) is when you need the same (or mostly the same) codebase to be 
backwards compatible with the old compiler for some time. The only 
trouble in this case is just verifying from time to time that you did 
not "leak" any ada 95 features into your code base.

In any case I've got about 150K SLOC of Ada 83 that I also use with an 
Ada 95 compiler (with Ada 83 being the primary compiler still for a 
variety of reasons) and I've only got 1 file that is branched to make 
the Ada 83 work with the Ada 95 compiler because it is Ada 95 (note 
there are 5 or 6 other branched files but these are branched due to some 
vendor specific library issues or other areas that are due to vendor 
differences and not Ada language revision differences).

Re: ADA compilers

[Keith Thompson]

"Patty" <patricia.l.addiss@honeywell.com> writes:
> Yes, we are trying to port an existing application.  I have looked at
> GNAT, but they only have ADA95.

Most valid Ada 83 programs are valid Ada 95 programs with the same
semantics.  Most of the exceptions (such as using new keywords as
identifiers) are easy to fix.

Try compiling the application with GNAT (or with any Ada 95 compiler).
You're likely to run into more problems going from one compiler to
another than going from Ada 83 to Ada 95, especially if the program
uses any compiler-specific features -- and you're going to have to fix
those problems anyway.

Since Ada 83 compilers are, for the most part, no longer being
maintained, you might not be able to find one that works with a newer
operating system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

Re: ADA compilers

[Björn Lundin]

2005-06-03 kl. 21.12 skrev Patty:

> Yes, we are trying to port an existing application.  I have looked at
> GNAT, but they only have ADA95.
>
We have ported a fairly large system from Ada83 to Ada 95 (Ie using an 
Ada 95 compiler on Ada83 code)
with hardly no problems. The things to watch out for is if you have 
variable names that
are the same as the new reserved words that Ada 95 brings. Ie you cant 
have a variable called 'aliased' since
that is a reserved word now.

We are using Gnat now, and had troble with some applications due to 
circular dependencies,
with the resukt that the Gnat compiler refused to link the application. 
The 'difficult' application contained heavy
use of tasking, in combination of a great deal of generic packages. The 
old compiler said OK, and so did other
Ada 95 compilers. Minor rewrite solved it.

A BIG difference with Gnat and other compilers are the way the Ada 
library a
is handled. We used it a lot, having several libraries in the same 
level, but not able to see each other.
ie
global
     level2-1
     level2-2
        level3
     level2-3

where the ones on level2 could all see global, but not each other. 
Level3 could see level2-2 and global but not the others

Of course, having different packages, with the same name, in all 
level2's is common in our system.
Tcl-script reading flat file'repository' based on current working 
directory, and
use of environment variables ADA_INCLUDE_PATH and ADA_OBJECT_PATH made
it possible to make it work, without having to use several projectfiles.

This was the
biggest challege

Then of course, packages using vendors spcifics, as how to get the 
command line, tasking policies
etc will differ.

Another thing to watch out for, if tasking is inviolved, is how the old 
compiler created tasks.
Is it run by the os like threads or locally in the runtime? This 
changes the way you can interact
with blocking io. We got a big boost using Gnat, because it made it 
possible to use
blocking io, instead of polling.

This was on Aix, but compiled and linked and tested (very very little) 
on Linux and mac os X as well

/Björn

Björn Lundin
bnl at spray dot se

Re: ADA compilers

[Björn Lundin]

2005-06-03 kl. 21.21 skrev Dmitry A. Kazakov:

> On 3 Jun 2005 12:12:01 -0700, Patty wrote:
>
>> Yes, we are trying to port an existing application.
>
> Egh, how to port Ada 83 to Ada 95 without Ada 95?

Porting to another OS perhaps?

The OP is looking for and ADA compiler for linux, not an Ada 95 
compiler.

/Björn

Björn Lundin
bnl at spray dot se

Re: ADA compilers

[Jeffrey Carter]

Patty wrote:
> Yes, we are trying to port an existing application.  I have looked at
> GNAT, but they only have ADA95.

I have used GNAT to develop Ada-83 code. In fact, I had to do so again 
only a couple of weeks ago. The -gnat83 switch turns GNAT into an Ada-83 
compiler.

Note that it's Ada, a woman's name, not the American Dental Association.

-- 
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24

Re: ADA compilers

[Martin Krischik]

Patty wrote:

> I am trying to find an ADA compiler for ADA83 for a Pentium/RedHat
> Enterprise Linux 3 operating system platform, but have not been able to
> locate one so far. Anyone know of one??

Well you can use gnat with the "-gnat83" option.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Ada compilers

[arkavae]

It is not clear for me what are the differents avaliables Ada compilers (except for GNAT) ? Is there an other company like Adacore producing Ada compilers ?

Re: Ada compilers

[Niklas Holsti]

On 12-11-24 17:55 , arkavae@gmail.com wrote:
> It is not clear for me what are the differents avaliables Ada
> compilers (except for GNAT) ? Is there an other company like
> Adacore producing Ada compilers ?

See http://www.adaic.org/ada-resources/ and in particular
http://www.adaic.org/ada-resources/pro-tools-services/.

AFAIK the only free/no-cost compiler is GNAT, but RR Software (link on
the page above) provides a low-cost compiler. Other compiler vendors
linked on the "pro tools" page are, AFAIK, Atego, DDC-I, Green Hills,
Irvine Compiler, and possibly (but perhaps no longer) OC Systems.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada compilers

[Gautier write-only]

On 24 nov, 16:55, arka...@gmail.com wrote:
> It is not clear for me what are the differents avaliables Ada compilers (except for GNAT) ? Is there an other company like Adacore producing Ada compilers ?

Hi.

Here is a list - not sure if complete...
http://unzip-ada.sf.net/#adacomp

Cheers
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address