GPasm question (probably gplink)

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GPasm question (probably gplink)

John Coppens
Hi all.

I'm in the midst of a hobby project, which grew larger than expected
(don't they always).

My project has several relocatable modules, and I noticed some strange
things. Say main.asm and moda.asm both have a section 'udata' and both
define several registers.

Now, if I declare something like this in mod_a.asm:

gpr0 udata
reg1 res 5
reg2 res 1

and then

hdr equ reg1+0
len equ reg1+1
...

then, hdr and len are always 0 based (not the address of reg1 + N).
The value of reg1 is correct - correctly appended to the gpr0 section
in main.

It looks as if gplink doesn't correctly patch up the equs.

Am I wrong in doing this?

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

Jan-Erik Söderholm


John Coppens wrote 2012-08-07 22:20:

> Hi all.
>
> I'm in the midst of a hobby project, which grew larger than expected
> (don't they always).
>
> My project has several relocatable modules, and I noticed some strange
> things. Say main.asm and moda.asm both have a section 'udata' and both
> define several registers.
>
> Now, if I declare something like this in mod_a.asm:
>
> gpr0 udata
> reg1 res 5
> reg2 res 1
>
> and then
>
> hdr equ reg1+0
> len equ reg1+1
> ...
>

I do not think you can mix RES symbols with EQU symbols that way.
They are not of the same "type" so to speak.

MPASM will give an error on this (even without "+0/1") :

"Operand contains unresolvable labels or is too complex"

Note that MPASM expects to know the value of the EQU (and SET)
symbols during assembly-time, the RES symbols are not known
until link-time (MPLINK or other linker). The value of reg1
is not important for MPASM (and probably GPASM). It's just
a name it passes over to MPLINK (or GPLINK).

But, a single UDATA section is always continus, so you can do:

myvars     udata
reg1_hdr   res    1
reg1_len   res    1
reg1_rest  res    3
reg2       res    1

And it will give you the same result, more or less.

Note also that it is normaly "better" to not use "gpr0" as
the name of the data section and let the linker decide
the bank where to put the section. You have to BANKSEL
anyway...

Jan-Erik.

 >

> then, hdr and len are always 0 based (not the address of reg1 + N).
> The value of reg1 is correct - correctly appended to the gpr0 section
> in main.
>
> It looks as if gplink doesn't correctly patch up the equs.
>
> Am I wrong in doing this?
>
> John
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

Mauricio Giovagnini
>________________________________
> De: Jan-Erik Soderholm <[hidden email]>
>Para: Microcontroller discussion list - Public. <[hidden email]>
>Enviado: martes, 7 de agosto de 2012 17:50
>Asunto: Re: [PIC] GPasm question (probably gplink)
>
>
>
>John Coppens wrote 2012-08-07 22:20:
>> Hi all.
>>
>> I'm in the midst of a hobby project, which grew larger than expected
>> (don't they always).
>>
>> My project has several relocatable modules, and I noticed some strange
>> things. Say main.asm and moda.asm both have a section 'udata' and both
>> define several registers.
>>
>> Now, if I declare something like this in mod_a.asm:
>>
>> gpr0    udata
>> reg1    res    5
>> reg2    res    1
>>
>> and then
>>
>> hdr    equ    reg1+0
>> len    equ    reg1+1
>> ...
>>
>
>I do not think you can mix RES symbols with EQU symbols that way.
>They are not of the same "type" so to speak.
>
>MPASM will give an error on this (even without "+0/1") :
>
>"Operand contains unresolvable labels or is too complex"
>
>Note that MPASM expects to know the value of the EQU (and SET)
>symbols during assembly-time, the RES symbols are not known
>until link-time (MPLINK or other linker). The value of reg1
>is not important for MPASM (and probably GPASM). It's just
>a name it passes over to MPLINK (or GPLINK).
>
>But, a single UDATA section is always continus, so you can do:
>
>myvars     udata
>reg1_hdr   res    1
>reg1_len   res    1
>reg1_rest  res    3
>reg2       res    1
>

My 2 cents here.  It has been a while since I don't code fluently in assembly but If I remember correctly I think he could also use overlay data, so he can place reg1_hdr, reg1_len and reg1_rest starting at the same location as reg1


There were some things to do with the linker like declaring a section and then declaring both vars in the same section or something like that.  As I said its been a while and I forgot the details.  I could dig more deeply in my older source codes if needed.

Mauricio

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

John Coppens
In reply to this post by Jan-Erik Söderholm
On Tue, 07 Aug 2012 22:50:45 +0200
Jan-Erik Soderholm <[hidden email]> wrote:

> I do not think you can mix RES symbols with EQU symbols that way.
> They are not of the same "type" so to speak.
>
> MPASM will give an error on this (even without "+0/1") :
>
> "Operand contains unresolvable labels or is too complex"

Hallo Jan-Erik,

I was afraid that error would appear. It already has many times. But it
seems that at least gpasm was satisfied with the equs in this case.

Strangely enough, I just tried and was able to solve the problem with
#define statements. Which _are_ correctly resolved!

#define hdr  reg1+0
#define len  reg1+1

> myvars     udata
> reg1_hdr   res    1
> reg1_len   res    1

Yes, I would have done that, if it weren't for the fact that the buffer
means different things in different contexts, so reg1+0 was a hdr in
some cases and had another meaning elsewhere.

> Note also that it is normaly "better" to not use "gpr0"
> let the linker decide

I didn't know that linker would make those choices (thanks), but I did
find that many of the predeclared labels for udata had strange values,
so I edited my own .lkr file for the project.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

John Coppens
In reply to this post by Mauricio Giovagnini
On Tue, 7 Aug 2012 14:08:06 -0700 (PDT)
Mauricio Giovagnini <[hidden email]> wrote:

> My 2 cents here.  It has been a while since I don't code fluently in assembly but If I remember correctly I think he could also use overlay data, so he can place reg1_hdr, reg1_len and reg1_rest starting at the same location as reg1

Hello Mauricio,

Thanks for the suggestion, but I believe the #define solution is more
simple.

If I were to use overlays, I probably would have to do the extra work
of locating the overlay section manually, wouldn't I?

John

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

Jan-Erik Söderholm
In reply to this post by John Coppens


John Coppens wrote 2012-08-07 23:08:

> On Tue, 07 Aug 2012 22:50:45 +0200
> Jan-Erik Soderholm <[hidden email]> wrote:
>
>> I do not think you can mix RES symbols with EQU symbols that way.
>> They are not of the same "type" so to speak.
>>
>> MPASM will give an error on this (even without "+0/1") :
>>
>> "Operand contains unresolvable labels or is too complex"
>
> Hallo Jan-Erik,
>
> I was afraid that error would appear. It already has many times. But it
> seems that at least gpasm was satisfied with the equs in this case.
>
> Strangely enough, I just tried and was able to solve the problem with
> #define statements. Which _are_ correctly resolved!
>
> #define hdr  reg1+0
> #define len  reg1+1
>

Well, yes. Since that is a simple *string* substitution.
There is never any symbol with the *numeric* value of reg1 + 1.
And it is (probably) not "resolved" by GPASM.

When you say "MOVLW hdr", it it expanded into "MOVLW reg1+1"
which works since it will be passed over to the linker to
be resolved at link-time... :-)

It's perfectly valid solution. And it makes it rellatively
easy to create multiple mapping of the same buffer. It's
just to add multiple defines.

Note that if your variables ends up in higher banks, the
address can be larger then 8-bits. That is what the
low/high qualifiers are for.

Now, in MPASM this works if written like :

myvars    udata
reg1      res    5
reg2      res    1

#define hdr  (reg1+0)
#define len  (reg1+1)

Then both these variations works:

MOVLW   hdr
MOVLW   low/high  hdr


Jan-Erik.




>> myvars     udata
>> reg1_hdr   res    1
>> reg1_len   res    1
>
> Yes, I would have done that, if it weren't for the fact that the buffer
> means different things in different contexts, so reg1+0 was a hdr in
> some cases and had another meaning elsewhere.
>
>> Note also that it is normaly "better" to not use "gpr0"
>> let the linker decide
>
> I didn't know that linker would make those choices (thanks), but I did
> find that many of the predeclared labels for udata had strange values,
> so I edited my own .lkr file for the project.
>
> John
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: GPasm question (probably gplink)

Jan-Erik Söderholm
In reply to this post by John Coppens


John Coppens wrote 2012-08-07 23:27:

> On Tue, 7 Aug 2012 14:08:06 -0700 (PDT)
> Mauricio Giovagnini <[hidden email]> wrote:
>
>> My 2 cents here.  It has been a while since I don't code fluently in assembly but If I remember correctly I think he could also use overlay data, so he can place reg1_hdr, reg1_len and reg1_rest starting at the same location as reg1
>
> Hello Mauricio,
>
> Thanks for the suggestion, but I believe the #define solution is more
> simple.
>
> If I were to use overlays, I probably would have to do the extra work
> of locating the overlay section manually, wouldn't I?
>

You use UDATA_OVR. All UDATA_OVR with the *same name* will have
the same start adress ("overlayed").

Example:

ovr1       udata_ovr
buf1_hdr   res 1
buf1_len   res 1
buf1_rest  res 3

ovr1       udata_ovr
buf1_hdr2  res 2
buf1_len2  res 1
buf1_rest2 res 2

This will create two overlayed definitions of the same
physical 5 bytes in memory.

Then you can have other overlayed sections with other names.

Note, this us MPASM, I do not know if this also works
the same in GPASM.

Jan-Erik.

> John
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist