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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!news-hog.berkeley.edu!ucberkeley!tethys.csu.net!nntp.csufresno.edu!sn-xit-03!sn-xit-09!sn-xit-08!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: CTips Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Teaching new tricks to an old dog (C++ -->Ada) Date: Tue, 08 Mar 2005 13:33:33 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <112rs0bdr2aftdf@corp.supernews.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> In-Reply-To: <395uqaF5rhu2mU1@individual.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@supernews.com Xref: g2news1.google.com comp.lang.ada:8870 comp.lang.c++:44634 comp.realtime:1070 comp.software-eng:4623 Date: 2005-03-08T13:33:33-05:00 List-Id: Peter Amey wrote: > > > Hans Malherbe wrote: > >>> support efficient, real-time safe environments >> >> >> >> Can you explain the "real-time" part? >> >> Reading this thread, it seems to me Ada's focus is on safety rather >> than efficiency. >> These safety constraints also tend to limit expressiveness. Not that >> safety is bad, just that it's not free. >> > > Actually, a close reading of the thread should have made it clear that > the additional safety is indeed "free". Free? Well, lets look at one particular issue: pointers to arbitrary locations. In C, its a common idiom to do the following: foo(int * p) { int * z; for( i ... ) { ... p[i]...; } z = p; } ... foo( &x[lo] ); ... Now, how can *any* language check to see that p[i] is within bounds? The usual solution is to pass p as a "handle"; basically, pass two pointers, one of which is the pointer to the descriptor of the containing "object" (which could be x or something containing x), or alternatively, pass a pointer to a record that contains x and p. z, in particular, will have to be a 2 element record, again containing x and p. A dereference via z will have to become a double dereference; first load p from z then load from p. Not quite free. > Since the majority of Ada's > checks are compile time they do not impact on run-time efficiency. > Where Ada's goals can only be met by run-time checks these are no more > expensive than equivalent manually-inserted checks in any other language > (and are often less because Ada provides the compiler with more > information by which to judge when they can safely be optimised away). Bullsh*t. In several ways, of which two are: - Usually the checks will be added every place they are needed, and then the usual optimizations will be used to eliminate them. In other words, if one adds the checks manually, the compiler should eliminate them identically. - Going back to the problem of finding the countaining object for some pointer. If one is adding the code by hand, one can use several options NOT available to a compiler. * what if z always points to objects inside x (but the compiler can't figure it out). * what if the containing object for p is always allocated on some 2^n byte boundary? There are other interesting things one can do for safety that are less memory/CPU intensive than what a language can give you automatically. Have a look at http://users.bestweb.net/~ctips for some of the ideas. > They can, in any case be turned off if the user requires a different > performance/safety tradeoff. Are you sure? Do I have to recompile the whole program in that case? Or reannotate the whole program? The above "handles" case is particularily pernicious. If a sub-program is compiled to not expect handles [because we just turned off that protection feature], but its caller is still passing handles, well - interesting things will ensue. > It should also have been clear from the thread that Ada imposes no > limits on expressiveness. How easy is it to build an arena allocator in Ada? Given a processor with load-word-locked and store-word-conditional, how would I build an atomic increment function? > Can you say what led you to the opposite conclusion? > > Peter >