Re: RFC: Saving and restoring the assembler state during assembly

[Dave Martin <dave dot martin at linaro dot org>]

Hi,

On Thu, Aug 11, 2011 at 4:22 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Dave Martin <dave.martin@linaro.org> writes:
>> However, there's not really anything fundamentally
>> architecture-specific about this problem, and ideally the solution and
>> the directives should not be architecture-specific either.
>> One option which appeals to me is to have some directives which can
>> exist across all architectures, and do something analogous to what
>> .set push and ,set pop do on MIPS.
>
> FWIW, this sounds like a really good idea to me. ?I won't argue about
> the syntax (I have no particular preference).

Thanks for the feedback.

>> I feel that the environment should also include global,
>> target-independent state such as the current macro mode (.altmacro
>> versus .noaltmacro) and current ELF section stack state, but not
>> symbols or macro definitions themselves.
>
> Sounds reasonable. ?To state the obvious, we'd have to make the existing
> target-dependent groupings (like .set push/pop on MIPS) work with this
> new scheme, but those directives musn't affect this extra target-independent
> information. ?So the new directives would interact with both the
> traditional .pushsection and the traditional target-dependent directives,
> even though those two features would otherwise remain independent.
>
> That is, .pushsection and .set push/pop operate on conceptually
> separate stacks whoses pushes and pops can be freely mixed.
> But .pushsection and the new directives would need to be
> strictly stacked; pops must have the same form as their
> corresponding pushes. ?Combinations of .set push/pop and
> the new directives would also need to be strictly stacked.

Exactly so -- I didn't spell it out in the previous mail, but I would
expect the MIPS .set push/pop directives to operate on a subset of the
state touched by the new directives, with a separate state stack from
that used by the new directives.  The .set push/pop stack (and
likewise PowerPC's .machine stack) shouldn't be manipulated by the new
directives.  This ought to allow for full backwards compatibility.

For directive nesting, your suggestion sounds sensible: because the
existing directives manipulate separate state, they must continue to
be freely mixable, but all push/pop pairs would need to be properly
nested around (or inside) any .pushenv/.popenv pairs.  Misuse should
be easy to detect by tracking the depth of the various stacks, and an
error can be thrown if the user does something bad.

This should mean that people can have new--style or old-style macros
and mix them without any unpleasant surprises, providing that any
macro containing a .pushenv has a matching .popenv.  (An unbalanced
directive in a macro is useful in certain situations though, and we
should allow it in the same way as for existing directives.  In such
cases, some competence would be required from the user, but that's not
different from the current situation.)

Cheers
---Dave