From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21991 invoked by alias); 9 Apr 2011 09:49:04 -0000 Received: (qmail 21974 invoked by uid 22791); 9 Apr 2011 09:49:02 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ppsw-41.csi.cam.ac.uk (HELO ppsw-41.csi.cam.ac.uk) (131.111.8.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Apr 2011 09:48:57 +0000 Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57644) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:nmm1) id 1Q8Umm-0008Li-S3 (Exim 4.72) (return-path ); Sat, 09 Apr 2011 10:48:56 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1Q8Umm-00084b-MC (Exim 4.67) (return-path ); Sat, 09 Apr 2011 10:48:56 +0100 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.3); 09 Apr 2011 10:48:56 +0100 Date: Sat, 09 Apr 2011 09:49:00 -0000 From: "N.M. Maclaren" To: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: Implement stack arrays even for unknown sizes Message-ID: In-Reply-To: <201104091056.57952.ebotcazou@adacore.com> References: <201104091056.57952.ebotcazou@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00679.txt.bz2 On Apr 9 2011, Magnus Fromreide wrote: >> >> There is actually a much better approach, which was done in Algol 68 >> and seems now to be done only in Ada. As far as the compiler >> implementation goes, it is a trivial variation on what you have done, >> but there is a little more work in the run-time system. >> >> That is to use primary and secondary stacks. ... > >How does your secondary stack interact with threads? Do it force the use >of more memory per thread? No, there is no difference. You need a pair of stacks per thread, rather than one, but that's all. On Apr 9 2011, Eric Botcazou wrote: > > Obviously this depends on the compiler. GNAT allocates all local arrays > on the primary stack for example. Interesting. I was relying on what (several) other people had told me. But, yes, it's entirely compiler-dependent, and can be done or not in any conventional 3GL language. >> You need a single secondary stack pointer (and preferably limit, for >> checking), which can be global variables. If a procedure uses the >> secondary stack, it needs to restore it on leaving, or when leaving >> a scope including an allocation - but you have already implemented >> that! > > Not exactly, managing a secondary stack isn't supported in the GENERIC > IL, you need to do it explicitly by inserting calls to the runtime at > relevant points. As a consequence, this isn't an efficient mechanism, > hence the restricted use. Naturally, every mechanism can be done badly, and I agree that it is very common for the best solution to be infeasible because of some other aspect. You still get the cache benefits with a pair of calls, but they do add a lot of overhead. Regards, Nick Maclaren.