gnupic: Re: [gnupic] Possible gpasm or gplink bug?
Subject:
RE: [gnupic] Possible gpasm or gplink bug?
From:
Chen Xiao Fan ####@####.####
Date:
14 Nov 2005 09:12:10 +0000
Message-Id: <3B8AEFFADD3DD4118F8100508BACEC2C0A2893A9@spex>
>No, Julian wants to get the offset into a string. In C he would write:
>
> &msg_to[RxState]
>
>In my opinion, Julian's example typifies a general problem with
>relocatable code; RAM variable addresses can't be accessed at assembly
>time. The one I hate is for overlaying temporaries. In the old days you
>could write:
>
>MeaningfulNameForALocalVariable EQU temp1
>
>This doesn't work for relocatable code (at least with gpasm and gplink)
>because the EQU (and SET) are not typed. Thus the EQU applies only at
>assembly time and what you want is an EQU that operates at link time.
>Maybe Olin's prepic macros address this issue, but I don't know. Or maybe
>there's a way other than udata_ovr to deal with this issue (and I don't
>know that either).
>
>Scott
I see. Thanks for the explanations.
The "MeaningfulNameForALocalVariable EQU temp1" method does not
work under MPASM/MPLINK as well.
Error[151] xxx.ASM 79 : Operand contains unresolvable labels or
is too complex
By using udata_ovr (lable udata_ovr specified_ram_address), the ram
address will be hard-coded to specified_ram_address. That could be
a solution but not a very good one.
Regards,
Xiaofan
