Re: macro behavior

Re: macro behavior

[Jan Beulich]

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

Re: macro behavior

[Hans-Peter Nilsson]

On Wed, 20 Apr 2005, Jan Beulich wrote:
> 	.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.

Whitespace separates parameters, not just comma, so I don't
think that'd be disambiguating.  I stand by my position that
allowing other than alphanumerics + _ in macro parameter names
is a walk down the wrong lane.  The powerpc symbol issue seems
to support that position.

(BTW, I agree with davem that your overlong lines makes
communication harder.)

brgds, H-P

Re: macro behavior

[Erik Christiansen]

On Fri, Apr 15, 2005 at 08:42:46AM +0200, Jan Beulich wrote:
> 
> Zack's suggestion seems very promising to me, though.

Yes, his suggestion is clearly going to solve ambiguity problems which
arise with the implicit appending that I've been using. 

> I'll look into whether that can be implemented without caveats.

That shell-like syntax would be a kindness to posterity.  :-)

Erik

Re: macro behavior

[Jan Beulich]

>>> Erik Christiansen <erik@dd.nec.com.au> 15.04.05 04:47:03 >>>
>On Thu, Apr 14, 2005 at 04:42:59PM +0200, Jan Beulich wrote:
>> (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:
>>
>> 	.macro m sym
>> 	.equiv &sym&_, 1
>> 	.endm
>
>   For me, prepending of constants, and appending of the constant '.' and
>parameter names works fine in gas. (Tested only on avr-as 20030512, so far,
>I'm afraid). For some odd reason, your choice of '_' does break the
>appending mechanism. Here is what works for me:
>
>  .macro struct_elem name, size, elem    ; Declare an element of struct "name"
>  \name.\elem = oneof_\name              ; Generate element offset.
>  oneof_\name = oneof_\name + \size      ; Size of one struct.
>  .endm

Without having tried it out, I'd say this doesn't work anymore in mainline; . previously wasn't considered a character valid for macro arguments, but now macro argument names follow the rules for symbol names (as they always should have), and thus \name.\elem now gets split into "\name." and "\elem" rather than "\name", ".", and "\elem".

>   If a more flexible syntax evolves, that would be nifty, but the
>existing code is in volume production, so is fixing what we have an
>option?  ;-)

Zack's suggestion seems very promising to me, though. I'll look into whether that can be implemented without caveats.

Jan

macro behavior

[Jan Beulich]

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:

	.macro m sym
	.equiv &sym&_, 1
	.endm

(the leading & is not even necessary in this mode, but to make the intentions clearer I added it). Any suggestions?

(2) In alternate mode, when using nested macros and/or repeat constructs (.irp, .irpc), each nesting level requires the number of &-s to be tripled; in default mode they just need to be doubled, and that's what I would have expected in alternate mode, too. Is this intentional? If not, are there any objections to fix this?
Comparing this with MASM (x86) behavior (which seems to be an assembler natively using these & macro operators), even that is too much * it just requires one additional & for each level, and permits using up as many as the deepest nested variable would require on variables from any level (thus allowing to leave the body of such a construct untouched when rearranging the nesting sequence).

Thanks, Jan

Re: macro behavior

[Zack Weinberg]

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

zw

Re: macro behavior

[Erik Christiansen]

On Thu, Apr 14, 2005 at 04:42:59PM +0200, Jan Beulich wrote:
> (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:
>
> 	.macro m sym
> 	.equiv &sym&_, 1
> 	.endm

   For me, prepending of constants, and appending of the constant '.' and
parameter names works fine in gas. (Tested only on avr-as 20030512, so far,
I'm afraid). For some odd reason, your choice of '_' does break the
appending mechanism. Here is what works for me:

   .macro struct_elem name, size, elem    ; Declare an element of struct "name"
   \name.\elem = oneof_\name              ; Generate element offset.
   oneof_\name = oneof_\name + \size      ; Size of one struct.
   .endm

   The following expands happily:

   .section .data,"aw"
   struct fruit
   struct_elem fruit,1,apple
   struct_elem fruit,3,orange
   struct_elem fruit,1,banana
   end_struct fruit,4            ; Array of 4 structs.

to:

  60                    .section .data,"aw"
  61                    struct fruit
  61                 > oneof_fruit =0
  62                    struct_elem fruit,1,apple              
  62                 > fruit.apple =oneof_fruit                
  62                 > oneof_fruit =oneof_fruit+1              
  63                    struct_elem fruit,3,orange
  63                 > fruit.orange =oneof_fruit
  63                 > oneof_fruit =oneof_fruit+3
  64                    struct_elem fruit,1,banana
  64                 > fruit.banana =oneof_fruit
  64                 > oneof_fruit =oneof_fruit+1
  65                    end_struct fruit,4         ; Array of 4 structs.
  65                 > sizeof_fruit =oneof_fruit*4
  65                 > numof_fruit =4
  65                 > fruit:.space sizeof_fruit
  65 0000 0000 0000  > .space sizeof_fruit
  65      0000 0000

allowing stuff like:

   ldd   r16,Y + fruit.banana   ; r16 = fruit[3].banana

   And, yep, it's '_' that is your bugbear with .equiv syntax also,
'cos this works too:

  64                    struct_elem fruit,1,banana 
  64                 > .equiv fruit.banana,oneof_fruit


   If a more flexible syntax evolves, that would be nifty, but the
existing code is in volume production, so is fixing what we have an
option?  ;-)

Erik