This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: macro behavior
- From: "Jan Beulich" <JBeulich at novell dot com>
- To: <binutils at sources dot redhat dot com>
- Date: Wed, 20 Apr 2005 11:20:06 +0200
- Subject: Re: macro behavior
>>> Zack Weinberg <zack@codesourcery.com> 14.04.05 19:25:51 >>>
>"Jan Beulich" <JBeulich@novell.com> writes:
>
>> I'm having two issue with dealing with macro parameters:
>>
>> (1) If I want to append a constant suffix to the expanded string, I
>> see no way to do so in default mode; in .altmacro mode I am able to do
>> so using the & macro operator:
>[...]
>
>I just tripped over this myself. I would suggest the following
>shell-like notation in default mode:
>
> .macro m sym
> .equiv \{sym}_, 1
> .endm
>
>This can't break anything else, because "{" is not currently an
>acceptable name for a macro parameter. I don't currently have time to
>implement it though.
Unfortunately this isn't true: On PPC, all of '{', '}', '[', and ']' are valid symbol name characters. I could see using
.macro m sym
.equiv \<sym>_, 1
.endm
as an alternative there or in general, or maybe make-like
.macro m sym
.equiv \(sym)_, 1
.endm
An additional question would then be whether we'd want to at least reserve the meaning of further shell-/make-like functionality, and hence initially forbid anything inside the braces/brackets/parentheses that isn't either itself an expansion or a symbol name, thus reserving the meaning of any non-symbol characters as potential future operators.
And there's actually another new piece of functionality I'd like to add - allowing for variable number of parameters, so that extending the functionality of things like .global becomes possible (pseudo-code for an ELF target):
.macro gproc name, ...
.global \name
.type \name, @proc
.ifnes "", "&..."
gproc \...
.endif
.endm
Of course, I don't want to make ... a special identifier here, so I'd rather like to go the MASM route and allow qualifiers on parameters (and at once introduce their .ifb/.ifnb pseudo-ops to not require use of the undocumented use of & in the .ifnes above):
.macro gproc name:req, more:vararg
.global \name
.type \name, @proc
.ifnb \more
gproc \more
.endif
.endm
These qualifiers mean
req argument value required
vararg parameter covers all remaining arguments, if any
while by default specifying an argument value would remain optional (including the use of =<value> to specify a default value). Of course, the use of : here again may present some issues, since MMIX allows : in symbol names, but other than above I think this could be tolerated, just requiring to use white space around the colon to disambiguate things.
Jan