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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.129.82.14 with SMTP id g14mr10482928ywb.37.1440232295550; Sat, 22 Aug 2015 01:31:35 -0700 (PDT) X-Received: by 10.182.246.7 with SMTP id xs7mr190794obc.37.1440232295518; Sat, 22 Aug 2015 01:31:35 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!69no2770932qgi.0!news-out.google.com!nt1ni11640igb.0!nntp.google.com!se8no8203849igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 22 Aug 2015 01:31:35 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.216.245.129; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 82.216.245.129 References: <2a592336-034f-4483-9aed-b5a1d997f902@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2541f7b7-b728-421b-96cf-e0d656e984a2@googlegroups.com> Subject: Re: How do typical Ada calling conventions work ? From: Hadrien Grasland Injection-Date: Sat, 22 Aug 2015 08:31:35 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 3430 X-Received-Body-CRC: 1952657938 Xref: news.eternal-september.org comp.lang.ada:27569 Date: 2015-08-22T01:31:35-07:00 List-Id: Le vendredi 21 ao=FBt 2015 14:47:05 UTC+2, Niklas Holsti a =E9crit=A0: > On 15-08-21 13:41 , Markus Sch=F6pflin wrote: > > Am 21.08.2015 um 10:37 schrieb Hadrien Grasland: > > > >> Does someone know how typical Ada implementations manage to cope with > >> this, and if it varies a lot from one implementation to another ? > > > > GNAT allocates such objects on the secondary stack. Quote from the user > > guide: > > > > ---%<--- > > `-Dnn[k|m]' > > This switch can be used to change the default secondary stack size valu= e > > to a specified size nn, which is expressed in bytes by default, or in > > kilobytes when suffixed with k or in megabytes when suffixed with m. > > > > The secondary stack is used to deal with functions that return a > > variable sized result, for example a function returning an unconstraine= d > > String. There are two ways in which this secondary stack is allocated. > > > > For most targets, the secondary stack is growing on demand and is > > allocated as a chain of blocks in the heap. The -D option is not very > > relevant. It only give some control over the size of the allocated > > blocks (whose size is the minimum of the default secondary stack size > > value, and the actual size needed for the current allocation request). > > > > For certain targets, notably VxWorks 653, the secondary stack is > > allocated by carving off a fixed ratio chunk of the primary task stack. > > The -D option is used to define the size of the environment task's > > secondary stack. > > --->%--- >=20 > I stumbled across an interesting, old discussion about GNAT's approach=20 > (it seems a secondary stack was not the initial choice) with references= =20 > to some other compilers: >=20 > http://computer-programming-forum.com/44-ada/2227f74c82f45451.htm >=20 >=20 > --=20 > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > . @ . Thanks for your answers ! These are some pretty nice ways to do it instead = indeed. I'm glad the secondary stack approach won in the end for GNAT, it sounds mo= re efficient, clean and scalable than what they were attempting in the begi= nning. Hadrien