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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Languages don't matter. A mathematical refutation Date: Sat, 4 Apr 2015 22:00:56 +0200 Organization: cbb software GmbH Message-ID: <32ecaopodr1g.1xqh7ssdpa2ud.dlg@40tude.net> References: <87h9t95cly.fsf@jester.gateway.sonic.net> <04f0759d-0377-4408-a141-6ad178f055ed@googlegroups.com> <871tk1z62n.fsf@theworld.com> <87oan56rpn.fsf@jester.gateway.sonic.net> <877fts7fvm.fsf@jester.gateway.sonic.net> <87twwv66pk.fsf@jester.gateway.sonic.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: w2sqUGEBZqsVBYNL7Ky3Kg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:25423 Date: 2015-04-04T22:00:56+02:00 List-Id: On Sat, 04 Apr 2015 12:20:39 -0700, Paul Rubin wrote: > Dennis Lee Bieber writes: >>>How big and complicated do those programs tend to be, if you don't mind >>>my asking? Do they have a lot of complex decision paths? >> It's not decision paths so much as deterministic timing... If there is >> a possibility of an operation triggering an arbitrary garbage collection > > Yes, I can understand why a realtime system can't use gc. Writing > simple programs without gc isn't too difficult. Writing complicated > programs without gc often means spending a lot of effort on manual > memory management and debugging memory errors. It is not manual vs. automatic. In Ada memory management is automatic except for some cases where the language design is flawed (e.g. task components and some cases of construction/destruction of limited and unconstrained types etc). It is explicit vs. implicit collection of non-scoped objects. > So I'm wondering if the > programs you wrote that way were complicated and if yes, how you dealt > with this issue. GC cannot deal with these issues because it does not have information necessary to determine implicit scope of the object. It is undecidable in most non-trivial cases. Reachability as a criterion does not work for complex structures, so management of scopes is required anyway by marking inter-object references as weak and strong and maybe with shades in between. >> (even if it is nothing more than combining adjacent free block into a >> single available block) then the operation is not permitted, on the simple >> basis that it makes the timing uncertain. > > In this case you may also have to consider the non-deterministic effects > of cache misses, if your cpu has cache memory; similarly for pipeline > stalls, serial multipliers, etc. Indeterministic time is of minor importance compared to indeterministic behavior in general, which means the program being non-testable and unmaintainable. Since GC cannot be statically analyzed, because if it could be, you would not need GC, having it non-testable eliminates all means of quality assurance. End of story. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de