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,9d929352a358ccab X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 26 Jan 2006 18:34:46 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1138132539.577082.206380@g43g2000cwa.googlegroups.com><87zmlkoz4k.fsf@mid.deneb.enyo.de><877j8oow1r.fsf@mid.deneb.enyo.de> <877j8ngrnx.fsf@mid.deneb.enyo.de> Subject: Re: Ada to C++ translator Date: Thu, 26 Jan 2006 18:39:37 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-hdH1t3eg6Q93addjo//+Fo+DPYC5mW15apFmSow/IKG3JJ+yGnjVtXQIOEP9ftDtEj8ee2Lttz9Jb/D!EfkIxb2qCSRiRI6JIllORcEn+F4t81GMCRUFUlVjrKhLJAbNLO5+A+lSdxz0Ac5LZXsHMG2xTBTL X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:2668 Date: 2006-01-26T18:39:37-06:00 List-Id: "Florian Weimer" wrote in message news:877j8ngrnx.fsf@mid.deneb.enyo.de... > * Randy Brukardt: > > > "Florian Weimer" wrote in message > > news:877j8oow1r.fsf@mid.deneb.enyo.de... > > ... > >> It's an abort-deferred operation (like assignment, which I should have > >> mentioned as well). > > > > That's expensive how? Abort-deferral is (or should be) just toggling a bit > > in the TCB. > > You need to find the TCB first, and you need to check for abortion > once deferral has ended. Especially the first part probably prevents > inlining on some POSIX platforms. Huh? The TCB has to be readily accessible, or the whole program isn't going to work at anything faster than a crawl. And the abortion check is just a check for an empty list (i.e. compare against null): it's only expensive if in fact there is a task on the list. But having abort be expensive is irrelevent. The TCB contains the heads of the exception and finalization chains (which also contains the temporary storage pools on Janus/Ada), the display registers (for up-level access), some temporaries for expressions (since the 80x86 architecture is register-poor), along with all of the tasking stuff. Essentially, it contains everything in Ada semantics that is task-specific. You have to have cheap access to that, or *everything* is bogged down (most subprogram calls have to do operations on the exception and finalization chains and with the display registers). On our never-quite-finished 68K compiler, we allocated a register permanently to the TCB. Our MS-DOS compilers used a global block for this stuff (and copied it each time a task switch happened - great for non-tasking programs, not so hot for tasking ones). I haven't studied the details of POSIX threads (they didn't exist when I last seriously worked on UNIX systems), but there is *always* a way to have easy access to thread-specific data. At worst, you'd have to allocate a register to finding it. There is a persistent myth that finalization, and particularly Ada finalization is expensive. But I've never seen any real evidence of that -- particularly in apples-to-apples comparisons. (No fair comparing an Ada program full of tasks with a C++ one that contains none, for instance.) Surely the cases where its tiny overhead really matters are very few in number. (OTOH, I'll grant that there is a space cost for it, and that can make a difference in some situations.) Randy.