Re: Compiler uses a lot of memory for large initialized arrays

[Ian Lance Taylor <ian@wasabisystems.com>]

Peter Barada <peter@the-baradas.com> 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