From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a77baf86c187076a X-Google-Attributes: gid103376,public 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 Message-ID: <54gb7a$nbh@linus.mitre.org>#1/1 X-Deja-AN: 190981814 references: <9610171549.AA07433@most> organization: The MITRE Corporation, Bedford Mass. newsgroups: comp.lang.ada Date: 1996-10-21T00:00:00+00:00 List-Id: 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