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=-0.1 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ae395e5c11de7bc9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder.news-service.com!eweka.nl!hq-usenetpeers.eweka.nl!news.mixmin.net!feeder.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: segfault with large-ish array with GNAT Date: Fri, 19 Mar 2010 13:20:19 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <642ddf8b-1d45-4f74-83ad-2c755040ca33@k24g2000pro.googlegroups.com> <4ba13454$0$6720$9b4e6d93@newsspool2.arcor-online.net> Injection-Date: Fri, 19 Mar 2010 13:20:19 +0000 (UTC) Injection-Info: feeder.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="31898"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QV4cGgfroCYFx0RIqxBLCXIH1VVqNYPQ=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:37/a8leyy3pLK3oSzcb5qdRLyGg= Xref: g2news2.google.com comp.lang.ada:10636 Date: 2010-03-19T13:20:19+00:00 List-Id: Ludovic Brenta expounded in news:bce19c00-0599-4ff6-a5cf-16bb3d742373 @e7g2000yqf.googlegroups.com: > Warren wrote on comp.lang.ada: >> Imagine >> a CPU that somehow in microcode was able to do a fast-malloc >> of a stack frame (as part of a call), linking the new >> frame back to the calling frame. Then you could eliminate >> the need for a "linear virtual stack region" altogether. This >> would allow code to freely fork into many parallel >> threads without the issue of pre-allocating stack [address] >> space to each new thread. When the called procedure executed >> a "return", it would (in microcode) free the current stack >> frame and return to the prior one. �The "call" allocate/free's >> could be constrained to one general "stack heap". > > I wonder how that would work with processors that have register > windows specifically to reduce the need for a memory-based stack (i.e. > SPARC, IA64 and maybe others). > > -- > Ludovic Brenta. I'm not sure I follow, but objects like small buffers would presumably still occupy the current stack frame. Warren