From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18331 invoked by alias); 15 Apr 2005 06:42:49 -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 18302 invoked from network); 15 Apr 2005 06:42:40 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 15 Apr 2005 06:42:40 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Fri, 15 Apr 2005 07:42:40 +0200 Message-Id: Date: Fri, 15 Apr 2005 06:42:00 -0000 From: "Jan Beulich" To: Cc: 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/msg00406.txt.bz2 >>> Erik Christiansen 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 "n= ame" > \name.\elem =3D oneof_\name ; Generate element offset. > oneof_\name =3D 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 whethe= r that can be implemented without caveats. Jan