From: Scott Dattalo <scott@da...> - 2002-01-06 17:11:18
I'm trying to implement data banking in the PIC port and would like to
hear from others on some good ways to approach it. As you may or may not
know, direct data accesses are encoded in 7-bits of a PIC's opcode.
Special bits in the STATUS register allow the address to be extended to
9-bits. However, the setting of the bank bits in STATUS require extra
bsf status,rp0 ; switch to bank 1
movf temp_in_bank1,w ; get a variable that's in bank 1
bcf status,rp0 ; switch back to bank 0
This will fetch a variable in bank1.
Now most pics have ram in at least two banks. Some have ram in four banks.
For compiler allocated variables, there's not a big issue. I can direct
SDCC what to do if RAM in the other banks needs to be used. For user
allocated variables, it's another issue.
For example, In SDCC you can declare data:
data at 0xa7 unsigned char uc1 = 0;
As it stands, this will cause an assemble EQU to be emitted. Fine.
However, if you look at the attributes of the symbol, you'll discover that
'volatile' is set. That's not good.
Should variable locating be left to the linker?
Is there a way to overide the volatile setting when the "data" modifier is
Should a new type be declared?
Should the default behavior of volatile be port dependent?
Yes the "at" keyword introduces the "volatile". The reasoning was that
"at" is used for memory mapped I/O devices access to these ports should
be volatile. May be it should become "port" dependent, SDCCsymt.c is the
> -----Original Message-----
> From: sdcc-devel-admin@...
> [mailto:sdcc-devel-admin@...]On Behalf Of Johan Knol
> Sent: Sunday, January 06, 2002 9:23 AM
> To: Scott Dattalo; sdcc-devel@...
> Subject: Re: [sdcc-devel] data banking
> > For example, In SDCC you can declare data:
> > data at 0xa7 unsigned char uc1 = 0;
> The "at" modifier implies volatile, not the "data" modifier.
> Maybe this need
> to be port dependent.
> sdcc-devel mailing list