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,6c7dea22b75ba442 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!eweka.nl!lightspeed.eweka.nl!feeder3.cambrium.nl!feeder2.cambrium.nl!feed.tweaknews.nl!193.201.147.87.MISMATCH!news.astraweb.com!border2.a.newsrouter.astraweb.com!xlned.com!feeder1.xlned.com!news.germany.com!news.banetele.no!news.hacking.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: ada compiler? Date: Fri, 16 Nov 2007 19:37:27 -0600 Organization: Jacob's private Usenet server Message-ID: References: <1194747665.6151.31.camel@K72> <_evZi.177931$Xa3.50640@attbi_s22> <87hcjq46t4.fsf@ludovic-brenta.org> <473abc9d$0$13104$9b4e6d93@newsspool2.arcor-online.net> <1195035988.599522.87580@50g2000hsm.googlegroups.com> <1195043147.1007.263.camel@kartoffel> <1195052954.315227.220840@o3g2000hsb.googlegroups.com> <1195056238.1007.317.camel@kartoffel> <1195058211.682783.288340@d55g2000hsg.googlegroups.com> <87pryb2e2k.fsf@willow.rfc1149.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1195263230 1576 69.95.181.76 (17 Nov 2007 01:33:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 17 Nov 2007 01:33:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:18451 Date: 2007-11-16T19:37:27-06:00 List-Id: "Samuel Tardieu" wrote in message news:87pryb2e2k.fsf@willow.rfc1149.net... > >>>>> "Ludovic" == Ludovic Brenta writes: ... > You have two ways of doing stack checking: > > 1- at the GCC level by checking the stack at the entry of every > subprogram and comparing it to a thread/task specific marker; this > is costly Calling this approach "costly" is ludicrous. There is a small space cost and the cost of a single integer compare. Compared to other subprogram linkage costs, it isn't significant. The only time that it isn't true is only really trivial subprograms that probably should have been inlined anyway. (I think inlining should be performed automatically in such cases.) Back in the very early days of Ada and RRS, we used to suppress all checking in the runtime libraries, because of the very limited memory of the Z-80 (we started with a 48K machine, the most you could have under vanilla CP/M was about 61K). We quickly had a number of mysterious bugs that eventually were traced into stack overflows occurring in the runtime system, especially Text_IO. It quickly became apparent that the tiny space saving was not worth the added headaches, and we quickly enabled stack checking everywhere by removing it from the effect of pragma Checks(Off);. Indeed, for many years we didn't even provide a way to turn it off (it got added when we implemented pragma Suppress (Storage_Check) for Ada 95). Yes, I've seen flaky stack behavior on Windows. But the problem wasn't with the stack check, but rather that Windows doesn't (didn't??) allocate stack pages until they are touched, and the stack can (could?) only be extended one page at a time, and allocating a large array on the stack could cause the stack to grow quickly. I hardly ever trust an OS to do something that I can do as well, because my experience is that the OS version does something subtly different that what you want. Everytime. That surely applies to stack checking - I've never been able to make an OS mechanism work "right".. (My holy grail would be an all-Ada system, but I realize that is not practical in the real world for the vast majority of applications - including mine.) Randy.