comp.lang.ada
 help / color / mirror / Atom feed
From: mfb@mbunix.mitre.org (Michael F Brenner)
Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA
Date: 1996/10/21
Date: 1996-10-21T00:00:00+00:00	[thread overview]
Message-ID: <54gb7a$nbh@linus.mitre.org> (raw)
In-Reply-To: DzL6J8.JG0@world.std.com


This argument that something is an implementation detail is used (often
by other people whose initials also happen to be RD). Why should that
invalidate the Requirement we have for those implementation details?
If we want Ada compilers to generate code that runs as fast as C code,
what is so wrong with that, particularly when the language has been 
designed to be highly optimizable. There has evolved a method of arguing 
down people who present their problems in this forum, which draws a magic
line as to what is a language requirement and what is an implementation
detail.   

I do not agree with where that line has been drawn. 

Let us start by defining an Ada compiler as a computer program that
translates Ada source code into object code (whether byte code, 
machine code, or an interpretive data structure which is not much 
more than annotated source code). 

The Requirements on this code fall into two categories: first, there
is a requirement to execute the object code in accordance with the
semantic meaning assigned by the reference manual with no errors such  
as memory leaks or sigsegv failures, and second, there is a Requirement
to meet the realtime expectations of the users. The first requirement
is of a different nature than the second, but is no more nor less 
important than the the second. If a compiler vendor places artificial
limitations on the capacity or the speed of the object code generated
by the compiler, users, such as myself will whine that we need more
capacity and speed. A valid answer to this need is not that we redefine
a compiler to not generate code, nor that speed is not a semantic 
requirement therefore it is not a requirement. In the original Rationale
efficiency of realtime embedded systems was The primary requirement 
of Ada and that efficiency was to be delivered in the most reliable 
fashion we could devise. The recent answers to all requests for 
efficiency on comp.lang.ada have lambasted the requestors with this
new-speak (that compilers are not translators and that efficiency 
is not a valid requirement). This has to stop. We have finished
defining the language, except for a very small number of mistakes
that have been discussed elsewhere in comp.lang.ada. IT IS TIME TO
DISCUSS HOW WE CAN GET THE EFFICIENCY NOW. Efficiency is not a game,
nor is it somebody's opinion, it is the primary factor in deciding
what language to use. Requests for efficiency, whether in tasking, 
garbage collection, unsigned numbers, in the code generated by
generic instantiations, or in dispatching should be taken seriously,
and recognized as a requirement on the same level as a semantic
requirement. When we revise the Ada Language Reference Manual next, it
should be fixed precisely in those places where more efficiency can
be put in without disturbing the reliability.
 
a requirement to do 




  reply	other threads:[~1996-10-21  0:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-10-17  0:00 Garbage collection (was a spinoff of a spinoff of a GA W. Wesley Groleau (Wes)
1996-10-20  0:00 ` Robert A Duff
1996-10-21  0:00   ` Michael F Brenner [this message]
1996-10-21  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA diatribe) Robert Dewar
1996-10-21  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA Larry Kilgallen
1996-10-21  0:00     ` Robert A Duff
  -- strict thread matches above, loose matches on Subject: below --
1996-10-21  0:00 W. Wesley Groleau (Wes)
1996-10-22  0:00 ` Jon S Anthony
1996-10-25  0:00   ` Jon S Anthony
1996-10-25  0:00   ` Robert I. Eachus
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox