From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8663 invoked by alias); 20 Apr 2005 09:20:07 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 8561 invoked from network); 20 Apr 2005 09:19:56 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 20 Apr 2005 09:19:56 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Wed, 20 Apr 2005 10:19:56 +0200 Message-Id: Date: Wed, 20 Apr 2005 09:20:00 -0000 From: "Jan Beulich" To: Subject: Re: macro behavior Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2005-04/txt/msg00542.txt.bz2 >>> Zack Weinberg 14.04.05 19:25:51 >>> >"Jan Beulich" 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 va= lid symbol name characters. I could see using .macro m sym .equiv \_, 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 it= self an expansion or a symbol name, thus reserving the meaning of any non-s= ymbol characters as potential future operators. And there's actually another new piece of functionality I'd like to add - a= llowing for variable number of parameters, so that extending the functional= ity 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 rathe= r 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 undocument= ed 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 (includ= ing the use of =3D to specify a default value). Of course, the use o= f : 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 u= se white space around the colon to disambiguate things. Jan