From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8973 invoked by alias); 2 Dec 2004 17:42:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 8944 invoked from network); 2 Dec 2004 17:42:16 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sourceware.org with SMTP; 2 Dec 2004 17:42:16 -0000 Received: (qmail 29171 invoked by uid 10); 2 Dec 2004 17:42:15 -0000 Received: (qmail 6113 invoked by uid 500); 2 Dec 2004 17:42:04 -0000 From: Ian Lance Taylor To: Peter Barada Cc: nathan@codesourcery.com, richard.guenther@gmail.com, stevenb@suse.de, joseph@codesourcery.com, mark@codesourcery.com, gcc@gcc.gnu.org Subject: Re: Compiler uses a lot of memory for large initialized arrays References: <425929.1102007117190.SLOX.WebMail.wwwrun@extimap.suse.de> <84fc9c000412020912298ed15c@mail.gmail.com> <41AF4E27.7070606@codesourcery.com> <20041202172949.9C1119842C@baradas.org> Date: Thu, 02 Dec 2004 17:42:00 -0000 In-Reply-To: <20041202172949.9C1119842C@baradas.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-12/txt/msg00139.txt.bz2 Peter Barada writes: > I was going to suggest using .org to go back and overwrite the > previous value in the assembler code(since you can compute the offset > quite easily, at least for arrays), but I see the GAS .org info page > has the following: > > `.org' may only increase the location counter, or leave it > unchanged; you cannot use `.org' to move the location counter > backwards. > > Because `as' tries to assemble programs in one pass, NEW-LC may not > be undefined. If you really detest this restriction we eagerly await > a chance to share your improved assembler. > > So I have to ask how many GCC targets *don't* use GAS? If that is > very few(to none), then perhaps the best solution is to look into > modifying GAS to allow backward setting of .org, or is that an even > bigger problem? Having gas support going backward with .org would be doable, though hardly simple. gas is not really a one-pass assembler, not since 1990 or so; it stores all the assembled data in memory, and then writes it out at the end of the assembly. (On the other hand, gas is also not really a two-pass assembler; it doesn't actually make another pass over the input, except to write out the data.) Backward .org could be supported with a new type of frag which specified the exact offset to use. When writing out that frag we would then use that offset, instead of just keeping track of the current offset as we do now. Several places in the assembler would need to be updated with information about the new frag type. Probably not much target dependent code would be involved. We would have to permit general expressions in the .org, or else it would be too hard for gcc to generate the correct expression. That is, gcc will want to generate ".org array + 10". Since the data following the .org can itself affect the placement of future symbols, some expressions will not be resolvable. Some attention would have to be paid to defining what would be permitted, and handling failing cases. This becomes particularly complex when using a backward .org in a code section for a target for which the assembler can relax branches, such as the i386 (or, for that matter, the Coldfire). There are certainly gcc targets which don't use gas, so any such optimization would have to be made conditional on support within the assembler. Ian