PPC Assembly: macros and unique label names

Jason Harris

unread,

Nov 11, 1996, 3:00:00 AM11/11/96

to

I was wondering if there is a way to generate unique label names for use
within assembly macros? Can the instruction address be embedded in the
name?

Can something like the following be done

$mylabel:
some code
b $mylabel

where the first branch would branch to the first occurance of $mylabel:
and the second branch to the second occurance of $mylabel?

I am using the m4 macro processor to include my macros within my source.
I would rather not put the code into a sub-routine and then branch and
link.

Cheers,

Jason

-----
Jason Harris | har...@nortel.ca
Nortel Technology | Tel: +61 42 233014
Wollongong, Australia | Fax: +61 42 242801

Michael Meissner

unread,

Nov 11, 1996, 3:00:00 AM11/11/96

to

In article <328671...@nortel.ca> Jason Harris <har...@nortel.ca> writes:

You didn't say what assembler you are using. Using the GNU assembler, you can
use 'Knuth' style numeric labels, ie:

1:
some code
b 1b

or

b 1f
some code
1:
--
Michael Meissner, Cygnus Support (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meis...@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)

Maynard Handley

unread,

Nov 11, 1996, 3:00:00 AM11/11/96

to

In article <328671...@nortel.ca>, Jason Harris <har...@nortel.ca> wrote:

> I was wondering if there is a way to generate unique label names for use
> within assembly macros? Can the instruction address be embedded in the
> name?
>
> Can something like the following be done
>
> $mylabel:
> some code
> b $mylabel
>
> $mylabel:
> some code
> b $mylabel
>
> where the first branch would branch to the first occurance of $mylabel:
> and the second branch to the second occurance of $mylabel?
>
> I am using the m4 macro processor to include my macros within my source.
> I would rather not put the code into a sub-routine and then branch and
> link.
>

It depends on the assembler.
Apple's PPCAsm supports macros directly and supports both labels internal
to macros, and labels that are redefined when reused.

maynard

--
My opinion only

Jason Harris

unread,

Nov 12, 1996, 3:00:00 AM11/12/96

to

Michael Meissner wrote:
>
> In article <328671...@nortel.ca> Jason Harris <har...@nortel.ca> writes:
>

> You didn't say what assembler you are using. Using the GNU assembler, you can
> use 'Knuth' style numeric labels, ie:

Oops, sorry aboout that. I'm using xlc on AIX.

I'll also elaborate a bit more on my problem.

If I have the macro:

define(MYMACRO, `
mylabel:
some code
b mylabel')

In my source I include the macros as such:

more code
MYMACRO
more code
MYMACRO
...

which gets expanded by m4 to:

more code
mylabel:
some code
b mylabel
more code
mylabel:
some code
b mylabel

AS can be seen, two labels called 'mylabel:' are created which leads to ambiguity as to
where the branch branches to. What I would like to happen is that each time the macro
MYMACRO is expanded in the code, 'mylabel' is modified to be unique.

Alan Booker

unread,

Nov 12, 1996, 3:00:00 AM11/12/96

to

Jason Harris wrote:
>
> I was wondering if there is a way to generate unique label names for use
> within assembly macros? Can the instruction address be embedded in the
> name?
>
> Can something like the following be done
>
> $mylabel:
> some code
> b $mylabel
>
> $mylabel:
> some code
> b $mylabel
>
> where the first branch would branch to the first occurance of $mylabel:
> and the second branch to the second occurance of $mylabel?
>
> I am using the m4 macro processor to include my macros within my source.
> I would rather not put the code into a sub-routine and then branch and
> link.
>

The following solution isn't very clean (did I hear butt ugly?)
but if you can tolerate the definition of a global the following
example might help....

define(counter,0)
define(my_macro,

label.$1:

`some code here '
`some more code here '
b label.$1
`define(`$1', incr($1))'
)

# instance 1
my_macro(`counter')

# instance 2
my_macro(`counter')
# end of example

m4 output of the preceeding example yields

# instance 1
label.0:

some code here
some more code here
b label.0

# instance 2
label.1:

some code here
some more code here
b label.1

Andrew Klossner

unread,

Nov 13, 1996, 3:00:00 AM11/13/96

to

> I was wondering if there is a way to generate unique label names for use
> within assembly macros? Can the instruction address be embedded in the
> name?

That's a function of the specific assembler. For example, with the
GNU assembler you can code local labels:

1: instruction
instruction
bdnz 1b

and the "1" need not be unique. "1b" refers to the first label found
going b(ackward) through the source; "1f" is its complement.

I think Knuth invented this convention in the late 60s. I'm surprised
that it hasn't been more widely implemented.

-=- Andrew Klossner (and...@teleport.com)

Marty Flickinger

unread,

Nov 14, 1996, 3:00:00 AM11/14/96

to Jason Harris

Jason Harris wrote:
> I was wondering if there is a way to generate unique label names for use
> within assembly macros? Can the instruction address be embedded in the
> name?

Both PPC assemblers I've used so far allow temporary labels to be defined:

77: some code
b 77b

The 'b' indicates to take the nearest occurrence of the label, searching backwards.
Use 'f' to search forward. These labels can be any number other than 0. You can re-use
the same numeric label, which makes is perfect for use in a macro. Just avoid using
the same number for a temporary label outside the macro, in case such a branch ends up
spanning across a use of the macro, which would not give the desired results.

I'll bet your assembler supports this. Try it even if not documented, as one I
used didn't list this, but it worked :-)

---------------------------------------------------------------------
Marty Flickinger | Excerpt from my latest project:
Software Engineer | 000010001011100000101001000
QuVis, Inc. | 100010101111011000111010100
(913) 272-3656 | 110111101011100111000011001
ma...@quvis.com |
http://www.quvis.com | Whoever dies with the most toys... still dies
---------------------------------------------------------------------