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
next prev parent 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