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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: =?UTF-8?Q?Re:_How_to_get_Ada_to_=e2=80=9ccross_the_chasm=e2=80=9d?= =?UTF-8?Q?=3f?= Date: Sat, 5 May 2018 23:22:13 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <878t9nemrl.fsf@nightsong.com> <87h8nl50rw.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net vZ6xsQI3slCXFhYyr9LXkgJgNFvVwxlQD/koQX+Y5Hdbh+cjwo Cancel-Lock: sha1:zifFTZu5x8Ds0/MjzPHCu8fTd3k= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87h8nl50rw.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52016 Date: 2018-05-05T23:22:13+03:00 List-Id: On 18-05-05 23:02 , Paul Rubin wrote: > Simon Wright writes: >> OK, there may be no dynamic (heap) allocation in restricted secondary >> stack, but since it's allocated as part of the task stack you'd have a >> hard row to hoe proving that it won't overflow! Lick a finger and >> hope. ... >> https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fSecondary_005fStack.html > > Actually I don't understand why there is a secondary stack? In C++ such > objects are placed on the primary stack, which afaict works out about > the same way. If the object size is statically known (and recursion is > not allowed or is restricted to a known depth) then with luck one can > prove that the stack won't overflow. If the size is unknown then a > secondary stack doesn't seem to help. One reason is that when a function evaluates an expression that creates an object of a large, dynamic size (eg. an array expression) on the secondary stack, this object can be returned /in situ/ as the function's return value, without being copied. Stuff can be left on the secondary stack when a function returns; it does not have to be pushed/popped in synchrony with calls and returns. AIUI, GNAT uses a mark-release method for managing secondary stack allocations. This makes it still harder to compute a bound on the secondary-stack usage (to avoid stack overflow), but perhaps the dynamic size of the objects allocated on the secondary stack already prevents that computation, in practice, for typical applications. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .