gnupic: gpasm Ensure bank bits are correct
Subject:
Re: gpasm Ensure bank bits are correct
From:
"Eric Smith" ####@####.####
Date:
27 Apr 2002 19:34:03 -0000
Message-Id: <32906.64.169.63.74.1019935542.squirrel@ruckus.brouhaha.com>
> These messages and warnings are a new gpasm feature. With a few
> exceptions they operate identically to mpasm. Or rather, I don't know
> of any bugs.
>
> Like mpasm, gpasm does not monitor the state of any of the internal pic
> registers. It does not know when the bank bits are properly set.
> Because of this, gpasm will generate the message any time the register
> accessed is not in bank0.
>
> If you don't like the warning and you are sure the bank bits are set
> correctly, add an "errorlevel -302" to your source. This will suppress
> only the bank messages.
>
> There are some automatic methods for setting the bank bits using
> macros. Microchip has an appnote AN586 (?) that shows a few examples.
MPASM (and by extention, gpasm) really needs a directive whereby you
explicity TELL the assmbler what bank is active when a region of code
is going to be executed. It's been many years since I did x86 assembly
programming, but I seem to reccall an "assume" directive that did such
a thing.
The way it would work is that you would use the new directive, which
I'll call "asmbank", immediately before or after the instructions that
change the bank. So you could write:
movwf porta
bsf fsr,5
asmbank 1
movwf trisa
bcf fsr,5
asmbank 0
And, better yet, you could put the asmbank directive into a macro.
This works especially well if there's something you can put into
an expression to return the current (at assembly time) value of the
asmbank variable. However, even without a way to get the current
value into an expression, you can use "set" to track it yourself.
But that will work only if you never change the bank without using
the macros.
setbank macro n
if (n&1)>(curbank&1)
bsf status,rp0
endif
if (n&1)<(curbank&1)
bcf status,rp0
endif
if (n&2)>(curbank&2)
bsf status,rp1
endif
if (n&2)<(curbank&2)
bcf status,rp1
endif
curbank set n
asmbank n
endm
Now the code above is simply:
movwf porta
setbank 1
movwf trisa
setbank 0
Note that unlike the errorlevel approach, or Microchip's "banksel"
directive, or Microchip's macros, now the assembler can actually verify
that you've set the bank bits correctly for the variable you are accessing.
Or the banksel directive could be extended to also update the assembler's
idea of the current bank.
A further extension to maximize the usefulness of this would be to give
MPASM and gpasm a directive to tell it what registers are aliased in
multiple banks:
bankalias portb,portb+100h
bankalias trisb,trisb+100h
bankalias fsr,fsr+080h,fsr+100h,fsr+180h
; macro to alias a range of locations into all banks
allbanks macro first,last
variable i
i = first
while i<=last
bankalias i,i+080h,i+100h,i+180h
i = i+1
endw
endm
; on the 16F877 and similar parts, 70h..7fh are aliased in all banks:
allbanks 070h,07fh
So does this all make sense to everyone? Does it seem like a good idea?
Should gpasm drive MPASM's feature set now, rather than the other way
around?
Best regards,
Eric
