This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Re: .macro behavior
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 9 Feb 2005 04:23:30 -0500 (EST)
- Subject: Re: [PATCH] Re: .macro behavior
- References: <s209c6d8.000@emea1-mh.id2.novell.com>
On Wed, 9 Feb 2005, Jan Beulich wrote:
> >>> Hans-Peter Nilsson <hp@bitrange.com> 08.02.05 18:31:37 >>>
> >I thought you were talking about macro *parameter names*, as
> >that's the change that exposed the mistake in the MMIX
> >test-case. I agree the macro names themselves should be
> >freely chosen (anything but whitespace or whatever).
>
> I'm actualy talking about both, and since both are symbol names, both
> should get the same treatment as ordinary symbols (despite agreeing that
> for macro parameters the previous restriction is less hurting).
> Otherwise it's just inconsistent.
I don't see what's wrong with that. I'd say it actually
simplifies macro definitions and usage. The macro parameter
name is used only in a macro definition, as a placeholder. It's
no big limitation to make it alphanumeric_ only. Otherwise, the
macro writer that wants to cater to multiple GAS ports (say, in
a package similar to glibc) would have to avoid making the
parameter name followed by any non-space character at all, in
case some port has that character as part of an identifier.
Like what happened with ":" and mmix in gas/mmix/relax2.s.
You've changed semantics: this calls for at least a gas/NEWS
item.
brgds, H-P