gnupic: use of labels in macros in gpasm - howto and maybe bug?
Subject:
Re: use of labels in macros in gpasm - howto and maybe bug?
From:
Craig Franklin ####@####.####
Date:
29 Mar 2002 01:11:39 -0000
Message-Id: <3CA3BE12.7267F1E0@attbi.com>
Sounds like you need to use the LOCAL directive.
Please send be the example that generated the parse error. I will
review it.
Jesse Lackey wrote:
>
> Hello all,
>
> I'm writing a couple of semi-gnarly macros that require labels. I need
> to have a way for each instance of the macro to have unique labels,
> since labels definted in macros have global scope.
>
> For example, the macro:
> FooMac macro Arg0, Arg1
> some code
> btfss etc
> goto _hopover
> more code
> btfss etc2
> goto _anotherBranch
> return
>
> _hopover
> other code
> return
>
> _anotherBranch
> yet more code
> return
> endm
>
> needs to have _hopover be different each instance.
> The two schemes I've come up with:
> (1) pass unique symbols in for each labels in for each instance
> (2) pass a unique number in for each instance
>
> (1) would be to have _hopover and _anotherBranch themselves be arguments
> to the macro, and unique symbols would be passed in. This is a bit ugly
> in that one of my macros has 4 labels in it, and there could be any
> number of labels required for arbitrarily complex macros.
>
> (2) is a bit of cleverness: pass in a unique number, and use it to
> synthesize unique lables with #v(). i.e. pass in another argument,
> "Arg2" say, as a number, and use _#v(Arg2)_hopover, etc. to make
> _4_hopover if Arg2 is 4.
>
> Okay.
> (a) is there a better way than all this tomfoolery? I could use goto $1
> +- number, but I'd have to calculate number each time the code changed
> and if number is wrong it would produce hard to diagnose bugs.
> (b) I'm having problems with method (2) that don't make sense and may be
> gpasm bugs. Specifically, for one of the synthesized labels the first
> two goto _(label) assemble fine, but the third idential goto _(label)
> gives a parse error. Some of the parse errors give line numbers that
> are blank, also, so I suspect gpasm.
>
> Suggestions?
> I'm going to go back to (1) to work around these problems, but if anyone
> wants to give a serious look at the problem, if indeed it seems that
> gpasm has a bug, I'll put together a test case.
>
> Thanks in advance!
> Jesse
>
> --
> Bill Gates is a crook and millions of tax dollars have been spent
> prosecuting and convicting Microsoft of illegal business practices. Do
> not give them another dime until they have repaid the US government
> these costs.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
