gnupic: Trouble with macros conditionally generating code
Subject:
Re: Trouble with macros conditionally generating code
From:
Craig Franklin ####@####.####
Date:
20 Nov 2004 03:52:20 +0000
Message-Id: <419E6B9C.6050405@users.sourceforge.net>
Marco Pantaleoni wrote:
>On Fri, Nov 19, 2004 at 12:18:28AM -0800, Pete Elmore wrote:
>
>
>>the rest come from the instruction itself. So, I thought that I could
>>perform a simple test to see if we were crossing a page boundary, and if
>>so, to just use bsf and bcf to set/clear the appropriate bits. I came
>>up with the following:
>>
>>fcall macro label
>>
>>
>
>I've tried the same approach, and came up with the macro:
>
>fcall MACRO dest
> LOCAL callsite = $
> LOCAL curpage = (callsite / 0x0800)
> LOCAL destpage = (dest / 0x0800)
> IF (curpage == destpage)
> call dest
> ELSE
> ERRORLEVEL -306
> pagesel dest
> call dest
> ERRORLEVEL +306
> ENDIF
> ENDM
>
>(we've even used the same name! :-)
>
>
>
>>However, if I attempt to use the macro, I get errors like the following:
>>
>>menu.s:1:Error [116] Value of symbol "main_menu" differs on second pass
>>~ pass 1=1719, pass 2=1721
>>
>>
>
>I *think* I could have an explanation, but I don't know how gpasm
>works internally, so the following is only a guess.
>That said, I think that the assembler on the first pass doesn't now some
>of the addresses you are jumping into (at least not the ones for routines
>not yet defined). So on the first pass the macro will generate a simple
>call (when called from page 0), because the target address will be 0.
>But on the second pass, for "far" targets, the macro is expanded in a
>different way, so all subsequent labels are "shifted" in regard to the
>first pass. Hence the warning.
>
>
>
Correct.
>Cheers,
>Marco
>
>
>
