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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: How to get Ada to =?utf-8?Q?=E2=80=9Ccross?= the =?utf-8?Q?ch?= =?utf-8?Q?asm=E2=80=9D=3F?= Date: Sat, 05 May 2018 09:06:49 +0100 Organization: A noiseless patient Spider Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <878t9nemrl.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="4e9ac54f5fe97487ef701cdb12a6f4d6"; logging-data="5466"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19FN93exiFRbcnWkAr4hUWFhZOOcV/5fzU=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin) Cancel-Lock: sha1:TSiDfYegAvf1k0IQqrDyupMOSR8= sha1:fRzmEWdmZmaHBDxQ+kyYoYnEZDc= Xref: reader02.eternal-september.org comp.lang.ada:52001 Date: 2018-05-05T09:06:49+01:00 List-Id: Dennis Lee Bieber writes: > On Fri, 4 May 2018 22:07:37 +0300, Niklas Holsti > declaimed the following: > >>On 18-05-04 16:30 , Jere wrote: >>> The secondary stack is another example. >> >>That is not even a standard concept in Ada, but an implementation >>concept. >> > > And usage of such is not permitted in the avionics software to > which I've been exposed. Merely because it seemed to be a dynamically > allocated structure. That's true for unrestricted runtimes, but I hardly think you'd be using those in avionics software? (mind, when I worked on a missile guidance system, we used unrestricted GNAT on VxWorks. That work started in 2000, so we didn't have much experience with pragma Restrictions, and I wouldn't know how to check what restrictions GNAT supported then (3.16a1). Nowadays we have No_Secondary_Stack[1]. 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. In my Cortex GNAT RTS, the secondary stack is allocated in the stack of the wrapper procedure that calls the task body .. so secondary stack overflow would smash the stack of another task, most likely (primary stack grows down, secondary stack grows up). Ugh. [1] https://gcc.gnu.org/onlinedocs/gnat_rm/No_005fSecondary_005fStack.html