WinNT ADA compilers comparison

WinNT ADA compilers comparison

[Nicolas Brunot]

We saw several messages from people comparing behavior of different ADA
compilers
But usually this concerns executable size or performance, or why one
doesn't accept code accepted by the others.
Have somebody made comparison between different compilers for Win NT
(Gnat, Objectada, Rational, Janus, etc ...) concerning
- compile time
- bind and link time
- accept projects of more than 500 000 lines and several hundred source
files ADA code without problem

The annoucement of gnat 3.13 said that it would accept Microsoft linker
and objects.
Does anybody know if this is an option or if gnat 3.12 linker is no
longer supported in 3.13 ?
(We noticed poor performance concerning link time for Microsoft linker
when a great number of objects are involved, is there a regression
concerning link time between 3.12 and 3.13 ?)

Thank you for any information you have.

Nicolas BRUNOT

Re: WinNT ADA compilers comparison

[Lionel Draghi]

Thierry Lelegard wrote:
> 
...
> I would think that the most important "time" point is
> the performance of the generated code. You compile
> once but you run your application many times...
A lot of software that where more compiled than used :-)

________________________________________________________________________
Lionel Draghi                                 http://www.Ada-France.org/

Re: WinNT ADA compilers comparison

[tmoran]

From the old PIWG READ.ME, dated 8/31/90
"There are three (3) complete runs to be made on each computer/compiler
combination. The first run makes execution performance measurements on
Ada features and composite benchmarks. The second run makes a
composite compile speed measurement including linking and execution.
The third run compiles about 100 files from the SIGAda programming
contest winner, then compiles the same source code again as one file."

That might be a start.  I don't know if there's a newer version somewhere.

Re: WinNT ADA compilers comparison

[Stephen Leake]

Nicolas Brunot <n.brunot@cadwin.com> writes:

> We saw several messages from people comparing behavior of different ADA
> compilers
> But usually this concerns executable size or performance, or why one
> doesn't accept code accepted by the others.
> Have somebody made comparison between different compilers for Win NT
> (Gnat, Objectada, Rational, Janus, etc ...) concerning
> - compile time
> - bind and link time
> - accept projects of more than 500 000 lines and several hundred source
> files ADA code without problem

If you are seriously evaluating compilers, contact the vendors. ACT is
perfectly willing to help you evaluate GNAT; no up-front charge
involved. Other vendors should do the same; some come close.

> The annoucement of gnat 3.13 said that it would accept Microsoft linker
> and objects.
> Does anybody know if this is an option or if gnat 3.12 linker is no
> longer supported in 3.13 ?

The default linker is the GNU linker, which now accepts MS object
files. I'm not sure if GNAT can produce MS object files; if it can,
than you could use the MS linker. 

gcc has always had the capability of substituting different tools for
the different phases of compilation; preprocess, compile (to
assembler), assemble, link.

-- 
-- Stephe

Re: WinNT ADA compilers comparison

[Thierry Lelegard]

> Have somebody made comparison between different compilers for Win NT
> (Gnat, Objectada, Rational, Janus, etc ...) concerning
> - compile time
> - bind and link time

I would think that the most important "time" point is
the performance of the generated code. You compile
once but you run your application many times...

-Thierry
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: WinNT ADA compilers comparison

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 724 bytes --]


Stephen Leake a �crit dans le message ...
>The default linker is the GNU linker, which now accepts MS object
>files. I'm not sure if GNAT can produce MS object files; if it can,
>than you could use the MS linker.

Definitly. MS linker can be used to build executable from GNAT
object files. But this must be done by hand. There is not automatic
way to do that yet.

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"

Re: WinNT ADA compilers comparison

[Nicolas Brunot]

From the user point of view, I think that reliability comes first (without
it, you usually lose so much time that generated code performance is useless
and means nothing)
More than that, increase performance by 5 doesn't mean a lot.
After a user action :
he will find not acceptable the difference between 1s and 5s
he will not care or even notice the difference between 1ms and 5ms
(And I saw some developpers spending days for the second improvement, while
not even care about the first ..., usually the user is not very happy)

Even if this is the most important, that doesn't mean you don't have to care
about development cost (one of the original purpose of ADA language, with
reliability)
As far as we are concerned, our code is far from being compile and linked
just once !
During the development process, corrections, maintenance,..., and before the
software can be provided to a customer, the code is compiled and linked
thousands of times.
I know few developpers linking just once a day.

For us, the difference between 20s and 4mns for linking is more than
important (we actually saw that difference between some compilers for same
code and executable)

Lionel Draghi a �crit :

> Thierry Lelegard wrote:
> >
> ...
> > I would think that the most important "time" point is
> > the performance of the generated code. You compile
> > once but you run your application many times...
> A lot of software that where more compiled than used :-)
>
> ________________________________________________________________________
> Lionel Draghi                                 http://www.Ada-France.org/

Re: WinNT ADA compilers comparison

[Thierry Lelegard]

> From the user point of view, I think that reliability comes first 

Sure. Performance comes after reliablity.

> More than that, increase performance by 5 doesn't mean a lot.
> After a user action :
> he will find not acceptable the difference between 1s and 5s
> he will not care or even notice the difference between 1ms and 5ms
> (And I saw some developpers spending days for the second improvement, while
> not even care about the first ..., usually the user is not very happy)

There are two different points here:
1. The way the application (source code) is written
2. The way the compiler generates the binary code.

Spending days optimizing the less relevant part of an application
is the first point. I agree that this is useless.

But, on a code generator point a view, there is no difference
in optimizing from 5s to 1s and from 5ms to 1ms. The first case
is most of the time (roughly) a loop of 1000 iterations of the
second case in the source code.

The quality and speed of the generated code is an instrinsic
quality of a compiler. To address the full range of applications,
a compiler must make it right. Let me briefly describe two cases
I experienced where it made all the difference:

- Years ago, I spent two days optimizing a few ms in a matrix
calculation. Why? It was in a Sonar software and the extra
ms missed the next hit.

- Currently, we sell software products to customers. These
software process huge amount of data and we must produce
new versions on a regular basis. Our customers have invested
a lot of money in large computers which are consequently
accurately sized for our software. If the generated code
becomes poor, then the customers must invest in larger
systems, which is not acceptable on a commercial point
of view.

So, yes, the performance of the generated code is not
important for hobbyists, educational institutions, GUI
software, desktop tools, etc. But, for commercial 
industrial software products, it is essential.

> I know few developpers linking just once a day.
> For us, the difference between 20s and 4mns for linking is more than
> important (we actually saw that difference between some compilers for
> same code and executable)

I agree. But it is also true that many Ada tools (including
compilers) are written in Ada. So, improving the compile time
is simply a nice side effect of improving the generated code
performance.

BTW, I also noticed the same magnitude of difference
between compilers, maybe we used the same two...

-Thierry
________________________________________________________
Thierry Lelegard, Paris, France
E-mail: lelegard@club-internet.fr

Re: WinNT ADA compilers comparison

[Nicolas Brunot]

> >But, on a code generator point a view, there is no difference
> >in optimizing from 5s to 1s and from 5ms to 1ms. The first case
> >is most of the time (roughly) a loop of 1000 iterations of the
> >second case in the source code.

I don't completely agree on that. when I talk about optimizing from 5s to 1s, or
from 5ms to 1 ms, this usually concerns completely different code part, and of
course, this optimization must concern the total amount of time that the user is
waiting after his command (and I was talking about software with important GUI
where ease of use of GUI is much more important than time computation to get the
result expected)

> >The quality and speed of the generated code is an instrinsic
> >quality of a compiler. To address the full range of applications,
> >a compiler must make it right. Let me briefly describe two cases
> >I experienced where it made all the difference:

I think that quality and speed of the same compiler can change a lot depending on
the kind of ADA feature and syntax you use.
(simple ADA83 compatible syntax, tasks, tagged type etc ...)
One very good compiler for one purpose can be very bad for another. We
unfortunately had to deal with compiler trying to be excellent in one field
(float computation) and by consequence being very poor in reliability when
interfering with others libraries.
If you are concerned by executable size for example, even with optimization and
strip, for example, we get gnat executable size incredibly huge in comparison
even with old ADA83 compiler (40 Mo instead of 8 Mo !!!)

> >So, yes, the performance of the generated code is not
> >important for hobbyists, educational institutions, GUI
> >software, desktop tools, etc. But, for commercial
> >industrial software products, it is essential.

I don't know what you mean by commercial industrial software, but we develop CAD
and database Oracle application we call commercial (because we sell them) and
industrial (because we try to have an industrial approach of software
developping).
We talked with some people developping in ADA, and obviously we don't have at all
the same needs concerning compiler feature and reliability than people
developping embedded system for example.
For us, the speed of the application (not of code executable ..., that's not
always the same thing)  depends much more on the way you write the application,
than on the code speed generated by the compiler.
Especally in CAD, a good and well thought GUI can help the user win 1000 more
time than a compiler generating 10 times faster code.

What we expect from the compiler is to be reliable, fast to link (more than fast
to compile) and above all, be reliable enough so we don't need support or patches

(We still use an ADA83 compiler and we never had to call suppor not even once in
6 years for about 1 million lines ADA code, and today no ADA95 compiler is good
enough to replace it)
For our applications we absolutely don't care about a compiler generating float
operation twice faster, that would be of absolutely no use for our customers.
But a compiler simple robust with no problem (even if it's not the best generated
code) and fast link, allows us to develop much faster and provide really useful
improvement for the customer.

Nicolas BRUNOT

Re: WinNT ADA compilers comparison

[G. de Montmollin]

Nicolas Brunot wrote:

> If you are concerned by executable size for example, even with optimization and
> strip, for example, we get gnat executable size incredibly huge in comparison
> even with old ADA83 compiler (40 Mo instead of 8 Mo !!!)

Strange - it ressembles to the GNAT / Alsys ratio on large projects...
But: did you apply the -gnatp option ?

The mass of code generated by GNAT (an generally by GCC), even with
effective optimisations, stripping etc., still intrigues me.
Of course, basically GCC was surely developed in a protected world
with Unix stations having "unlimited" storage, and without commercial
worries, but does anyone know what is all that stuffing ?...

______________________________________________________
Gautier  --  http://members.xoom.com/gdemont/gsoft.htm

Re: WinNT ADA compilers comparison

[Laurent Guerby]

Nicolas Brunot <n.brunot@cadwin.com> writes:
> [...] If you are concerned by executable size for example, even with
> optimization and strip, for example, we get gnat executable size
> incredibly huge in comparison even with old ADA83 compiler (40 Mo
> instead of 8 Mo !!!) [...]

Hmmm, do you have lots of generics? If the old compiler implements
shared generics and given that GNAT doesn't, that could be a reason
for the size difference. BTW, did you try "-Os"? It asks GCC to try to
avoid optimizations that increase code size.

Also, what is the platform here?

-- 
Laurent Guerby <guerby@acm.org>

Re: WinNT ADA compilers comparison

[n_brunot]

Storage start to be not so unlimited when you reach sizes of more than
40 or 50 Mo ...

In article <397DC549.250331FF@maths.unine.ch>,
  "G. de Montmollin" <gautier.demontmollin@maths.unine.ch> wrote:
> Nicolas Brunot wrote:
>
> > If you are concerned by executable size for example, even with
optimization and
> > strip, for example, we get gnat executable size incredibly huge in
comparison
> > even with old ADA83 compiler (40 Mo instead of 8 Mo !!!)
>
> Strange - it ressembles to the GNAT / Alsys ratio on large projects...
> But: did you apply the -gnatp option ?
>
> The mass of code generated by GNAT (an generally by GCC), even with
> effective optimisations, stripping etc., still intrigues me.
> Of course, basically GCC was surely developed in a protected world
> with Unix stations having "unlimited" storage, and without commercial
> worries, but does anyone know what is all that stuffing ?...
>
> ______________________________________________________
> Gautier  --  http://members.xoom.com/gdemont/gsoft.htm
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: WinNT ADA compilers comparison

[n_brunot]

I use deja.com since I'm currently in Japan and have problems accessing
newsgroup from my usual account.

Platform is WinNT 4 with Gnat 3.12p
we tried a lot of optimisation, strip etc ...

In comparison to others compilers (not only Alsys ADA83) Gnat produces
incredibly huge executables when you make intensive use of generics
(using a lot of generics is a quite normal and desirable thing in ADA
according to us)

We of course use generics (and generics of generics ....) which is may
be one of the most important and powerful ADA features, allowing you
not spending your time writing more or less the same code, and keep
strong compiler check.

reaching sizes of more than 40 or 50 Mo start to be a real inconvenient
when others compilers are 4 or 5 times smaller

Nicolas BRUNOT

In article <86zon5aio7.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:
> Nicolas Brunot <n.brunot@cadwin.com> writes:
> > [...] If you are concerned by executable size for example, even with
> > optimization and strip, for example, we get gnat executable size
> > incredibly huge in comparison even with old ADA83 compiler (40 Mo
> > instead of 8 Mo !!!) [...]
>
> Hmmm, do you have lots of generics? If the old compiler implements
> shared generics and given that GNAT doesn't, that could be a reason
> for the size difference. BTW, did you try "-Os"? It asks GCC to try to
> avoid optimizations that increase code size.
>
> Also, what is the platform here?
>
> --
> Laurent Guerby <guerby@acm.org>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: WinNT ADA compilers comparison

[gdemont]

Nicolas BRUNOT:

> Platform is WinNT 4 with Gnat 3.12p
> we tried a lot of optimisation, strip etc ...

Did you avoid inlining (-gnatn or -gnatN) too ?
A solution would be to share more instanciations of generics
e.g. having common subtypes. Create 1-line packages for those
generic ones used many times:
"with such_generic; package such_inst is new such_generic(x,y,z);"
If there are many main procedures p1, p2,...
(-> several linked executables p1.exe, p2.exe)
using almost the same packages, shell them through a common one
"with p1,p2,...; procedure p is..."

> In comparison to others compilers (not only Alsys ADA83) Gnat produces
> incredibly huge executables when you make intensive use of generics
> (using a lot of generics is a quite normal and desirable thing in ADA
> according to us)
>
> We of course use generics (and generics of generics ....) which is may
> be one of the most important and powerful ADA features, allowing you
> not spending your time writing more or less the same code, and keep
> strong compiler check.
>
> reaching sizes of more than 40 or 50 Mo start to be a real inconvenient
> when others compilers are 4 or 5 times smaller

And what makes you unhappy with the Ada95 compilers other than GNAT ?

G.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: WinNT ADA compilers comparison

[n_brunot]

In article <8m9a08$pu7$1@nnrp1.deja.com>,
  gdemont@my-deja.com wrote:

> Did you avoid inlining (-gnatn or -gnatN) too ?
> A solution would be to share more instanciations of generics
> e.g. having common subtypes. Create 1-line packages for those
> generic ones used many times:
> "with such_generic; package such_inst is new such_generic(x,y,z);"
> If there are many main procedures p1, p2,...
> (-> several linked executables p1.exe, p2.exe)
> using almost the same packages, shell them through a common one
> "with p1,p2,...; procedure p is..."

We try not introducing any changes in our specifications and tools just
to satisfy one compiler if all others are happy with a perfectly
satisfying code (especially a compiler we don't use for release version)
We prefer to wait that the compiler works fine with code ok for all
others compilers.
We always check our code with several compilers in order to keep our
code as much independant as possible from the compiler, even for one
single platform.
Some compilers don't have the same behavior, and a perfectly bad code
can work very well on a very good compiler.
It's a very good way to chase bad or non portable code with this
method, and it's doesn't make you lose a lot of time (and you win a lot)

gnat 3.12p is one we use to check our code, but anyway it is unusable
for our applications due to its very poor reliability when components
of foreign code are called under WinNT, (see discussion for
float_io.put on gnat chat july archives www.gnat.com)
Gnat works in a very different way than others compilers which makes it
a good check tool even if we don't use it for release versions.
Of course a (very expensive) supported version exists, and bugs could
be quickly solved, but we think it's not a good thing that support is
needed for basic reliability problems .

Compiler vendor often forget than even if their support answers and
provides a patch in less than 1 hour, the time to detect the problem
(especially hardly noticeable ill behavior without warning or crash,
and especially if it's detected after official release), isolate it,
contact support, get the patch, make a new version of your application,
providing it to your customers, is of incredibly high cost.

It's much better to have a not so good support you need once every two
years, than an excellent support you need every 3 monthes.

>
> And what makes you unhappy with the Ada95 compilers other than GNAT ?
>
> G.

Currently we have more than 1 million ADA lines code compiled with an
ADA 83 compiler. We never need any support in 5 or 6 years.
We test several compilers to switch to ADA95 (our code is designed so
we have very few specific units requiring different code for ADA83 and
ADA95) and we are not in a hurry.
Nothing makes us unhappy with others ADA95 compilers
We just take the time to check internally our softs compiled with
others compilers, and compare the easy of use, time required to
compile, link etc ...



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: WinNT ADA compilers comparison

[Brian Rogoff]

On Thu, 3 Aug 2000 n_brunot@my-deja.com wrote:
> In article <8m9a08$pu7$1@nnrp1.deja.com>,
>   gdemont@my-deja.com wrote:
> 
> > Did you avoid inlining (-gnatn or -gnatN) too ?
> > A solution would be to share more instanciations of generics
> > e.g. having common subtypes. Create 1-line packages for those
> > generic ones used many times:
> > "with such_generic; package such_inst is new such_generic(x,y,z);"
> > If there are many main procedures p1, p2,...
> > (-> several linked executables p1.exe, p2.exe)
> > using almost the same packages, shell them through a common one
> > "with p1,p2,...; procedure p is..."
> 
> We try not introducing any changes in our specifications and tools just
> to satisfy one compiler if all others are happy with a perfectly
> satisfying code (especially a compiler we don't use for release version)

To be clear here, it isn't that GNAT is unhappy (i.e., doesn't work) with
your code, it is that you are unhappy with the code size because your 
original code uses a style suitable with a generic sharing implementation 
and GNAT implements generics with macro expansion, like C++ compilers,
right? 

I guess I always code to a macro expanding implementation in Ada since I 
was raised on GNAT, but I see that this is a real issue if you are used to
something else. I don't know if GNAT is going to change anytime soon; 
Robert Dewar mentioned that there is a DEC patent on generic sharing which 
implementors had to be cautious of. Find the date it was issued, and add
17 to get an idea of when we might hear talk of a generic sharing GNAT ;-)

> gnat 3.12p is one we use to check our code, but anyway it is unusable
> for our applications due to its very poor reliability when components
> of foreign code are called under WinNT, (see discussion for
> float_io.put on gnat chat july archives www.gnat.com)

OK, that's a different issue.

-- Brian

Re: WinNT ADA compilers comparison

[tmoran]

>I don't know if GNAT is going to change anytime soon;
>Robert Dewar mentioned that there is a DEC patent on generic sharing which
>implementors had to be cautious of. Find the date it was issued, and add
>17 to get an idea of when we might hear talk of a generic sharing GNAT ;-)
  Janus Ada was using code sharing generics when I first used it about
a dozen years ago (they targetted PCs, which then had small RAM).

Re: WinNT ADA compilers comparison

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> Robert Dewar mentioned that there is a DEC patent on generic sharing which 
> implementors had to be cautious of. Find the date it was issued, and add
> 17 to get an idea of when we might hear talk of a generic sharing GNAT ;-)

First of all, the DEC patent covers just one method of generic code
sharing.

Second of all, there is prior art on that particular method.

- Bob

Re: WinNT ADA compilers comparison

[Robert I. Eachus]

n_brunot@my-deja.com wrote:

> In comparison to others compilers (not only Alsys ADA83) Gnat produces
> incredibly huge executables when you make intensive use of generics
> (using a lot of generics is a quite normal and desirable thing in ADA
> according to us)
 
> We of course use generics (and generics of generics ....) which is may
> be one of the most important and powerful ADA features, allowing you
> not spending your time writing more or less the same code, and keep
> strong compiler check.

     During the Ada 9X Requirements process, those of us at MITRE who
were
involved with supervision of government contracts had very few
corporate, as opposed to individual comments, on the proposed
requirements.

     The one thing that we all felt strongly about was that there were
"shortcomings" in the Ada language that should not be fixed.  Why? 
Because when a project ran into one of these "major problems" with Ada,
they would complain about the language, we would get called in, and in
most cases a design fix that was very inexpensive AT THAT POINT IN THE
PROJECT would eliminate both the major design problem and the problems
that the contractor was attributing to the language or the compiler.

     One simple example is "slow compilation times."  If your project is
making changes every day that require recompiling a substantial fraction
(or all!) of the source code, then the problem is not that Ada has these
nasty recompilation rules, it is that your design is not using
information hiding correctly, and that the final code will almost
certainly be unmaintainable.

     Another example, and the one that you seem to be tripping over, is
proper use of generics.  There is noting wrong with generics nested in
generics, and generic instantiations that instantiate other generics,
etc.  But you need to know for each generic and each instantiation
whether or not the compiler should do inlining, and where.

     But isn't that an implementation detail you say?  Sure it is, and
it is nice that the Ada language is designed so that changing those
decisions can be done by changing a couple of pragmas in the source
code.  But the decisions that can and should be delayed until later in
the project do not include code size limitations and timing of key
threads.  Those issues need to be thought out during the preliminary
design process and communicated to all members of the team, not just to
the design team.

     If those broad brush decisions are made correctly, and communicated
to the team, you won't have either code bloat or slow execution
surprises.  But no matter how intelligent the compiler is on the issue
of inlining and generics, the compiler doesn't know what the intent of
the design team is.  Pragmas and compiler switches can communicate that
information to the compiler, but if the design team hasn't considered
those issues, how can the compiler be expected to make those decisions
correctly.  (Also there are cases where what you really want to do is to
use generics to express templates, and the body of the generic template
needs to be written as a template.  The generic subprogram, or more
usually, the subprograms in a generic package, will be designed to be
inlined, but most or all of the actual code will be in subprograms that
are non-generic, and not inlined.  The Gnat Text_IO library has some
good examples of this.)

     So if your compiler is making incorrect implementation decisions,
the fault is usually not in the compiler, but in the directions that it
is given.  And even when the compiler is guessing right, you should
still tell the compiler what to do, and document it carefully, if the
decision is a key part of the overall design.  This is why the usual
advice is to use pragmas, often with very restricted scopes, rather than
compile-time switches.  The pragma puts the documentation where it
belongs--and will be seen by maintainers.  This is one reason why
pragmaa Unsuppress is being standardized.  It allows the programmer to
document that a particular exception is an expected part of this piece
of code, and any necessary checks should made here, even if the check is
turned off globally by a pragma or by a compile-time switch.

Re: WinNT ADA compilers comparison

[n_brunot]

  "Robert I. Eachus" <rieachus@earthlink.net> wrote:
>      One simple example is "slow compilation times."  If your project
is
> making changes every day that require recompiling a substantial
fraction
> (or all!) of the source code, then the problem is not that Ada has
these
> nasty recompilation rules, it is that your design is not using
> information hiding correctly, and that the final code will almost
> certainly be unmaintainable.

In a software development company, making code changes is your dayly
job.
I talked about compiling, but above all, binding and linking time,
because as far as I know, we have to bind and link after the slightest
code change ...
I don't know if our code design is good, but we've been very
successfully maintaining it for more than 10 years, and hope to continue
...


>      Another example, and the one that you seem to be tripping over,
is
> proper use of generics.  There is noting wrong with generics nested in
> generics, and generic instantiations that instantiate other generics,
> etc.  But you need to know for each generic and each instantiation
> whether or not the compiler should do inlining, and where.
>


I wasn't talking about proper or improper use of generics in ADA, but
just noticing that Gnat executables are incredibly huge in comparison
with others compilers when you use generics.
We don't develop compilers and don't intend to do it, we just compare
available ones, and choose the one which best meet our needs ...
From the compiler user point of view, If everything else is equal,
providing 8 Mo executable is of course better than providing 40 Mo
executable

>      But isn't that an implementation detail you say?  Sure it is, and
> it is nice that the Ada language is designed so that changing those
> decisions can be done by changing a couple of pragmas in the source
> code.  But the decisions that can and should be delayed until later in
> the project do not include code size limitations and timing of key
> threads.  Those issues need to be thought out during the preliminary
> design process and communicated to all members of the team, not just
to
> the design team.
>

About preliminary design process, I think that everybody agree on what
should be done, and what anybody writing software must try to reach.
But unfortunately, theory is sometime not applicable in the real world.
I know some (a lot ?, all ?) cases where perfect theory would
indefinitely command to start again the project which therefore would
never get out the development team.


Sent via Deja.com http://www.deja.com/
Before you buy.