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