From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20872 invoked by alias); 14 Apr 2005 14:43:15 -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 20344 invoked from network); 14 Apr 2005 14:42:54 -0000 Received: from unknown (HELO emea1-mh.id2.novell.com) (195.33.99.129) by sourceware.org with SMTP; 14 Apr 2005 14:42:54 -0000 Received: from EMEA1-MTA by emea1-mh.id2.novell.com with Novell_GroupWise; Thu, 14 Apr 2005 15:42:53 +0200 Message-Id: Date: Thu, 14 Apr 2005 14:43:00 -0000 From: "Jan Beulich" To: Subject: macro behavior Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2005-04/txt/msg00371.txt.bz2 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 th= e & macro operator: .macro m sym .equiv &sym&_, 1 .endm (the leading & is not even necessary in this mode, but to make the intentio= ns 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; i= n default mode they just need to be doubled, and that's what I would have e= xpected 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 nat= ively using these & macro operators), even that is too much * it just requi= res one additional & for each level, and permits using up as many as the de= epest nested variable would require on variables from any level (thus allow= ing to leave the body of such a construct untouched when rearranging the ne= sting sequence). Thanks, Jan