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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!bbn!inmet!ishmael!inmet!authorplaceholder From: ryer@inmet.UUCP Newsgroups: comp.lang.ada Subject: Re: limited private types Message-ID: <124000021@inmet> Date: 6 Dec 88 16:56:00 GMT References: <8197@nsc.nsc.com> Nf-ID: #R:nsc.nsc.com:-819700:inmet:124000021:000:2956 Nf-From: inmet.UUCP!ryer Dec 6 11:56:00 1988 List-Id: I agree it would be nice to be able to defer specifying the details of the private type until the body is compiled. Also, the reason for the present restriction is so that the compiler can know the size of the type. Implicitly generated heap objects would work ok (forcing all passage of private types by reference). HOWEVER: Ada now provides the pointer-based semantics when the user explicitly codes an access type. It ALSO provides the more efficient direct allocation/access when the user does not code a access type. The language changes proposed would eliminate one option. It is possible to build an Ada compiler which NEVER uses the heap or any sort of pointer to access ordinary objects of static sizes, and at least one is very careful of this. This is important to those who use Ada for realtime systems. Many actual private types in real programs turn out to be integers. Passing these by value makes a big difference in the performance of the generated code. (Often a procedure parameter is already in a register at the call site, and some optimizers contrive to make it the appropriate one so the cost for passing it is zero as compared to a store at the call site followed by a load in the caller). Some Ada applications are built for small machines with restricted memory and modest throughput and have to meet timing constraints that are very tight (e.g. 100 hertz). As we used to say in the Ada language design days, "any good compiler will resolve this", in this case by only introducing an implicit access type when the private type's definition is missing from the spec and otherwise generating the same code as now. I hope we've learned that compiler writers sometimes take the easiest path and defer the optimal approach to some future release. We've gone through years of performance problems with Ada because of compilers that weren't optimal. Efficient approaches were proposed for every language feature when the language was being designed, and features were dropped it nobody could come up with an efficient implementation. It turns out that compilers aren't as good as the language designers contemplated even now. There had been no mention of the impact on the generated code in this note stream and I had to post this flame. In the 9X cycle, we need to ask not only whether an efficient implementation is feasible, but whether it is likely to appear in most compilers within a reasonable time. I "vote" strongly against the proposal that ALL parameters should be passed by reference -- that clearly would make Ada less efficient on most machines however good the compilers are. The slow acceptance of Ada has been due to performance problems in the generated code and speed and reliability problems in the compilers, not due to a lack of flexibility in dealing with private types or other features. Lets not add complexity and reduce performance this time around. Mike Ryer Intermetrics, Inc.