Re: macro behavior

["Jan Beulich" <JBeulich@novell.com>]

>>> 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