gnupic: Thread: gpasm Ensure bank bits are correct

When assembling with gpasm I get the following:

init.asm:81:Message [302] Register in operand not in bank 0. Ensure bank
bits are correct.


I can use the "-w 1" to ignore these messages but is there a way to tell
gpasm that the correct bank bits have been set?

Thanks,

-- 
Anthony Tekatch

On Fri, 26 Apr 2002, Anthony Tekatch wrote:

>
> When assembling with gpasm I get the following:
>
> init.asm:81:Message [302] Register in operand not in bank 0. Ensure bank
> bits are correct.

a trick from Andy Warren:

    movf  (some_reg ^ 0x80), w

If some_reg is in bank1, then the xor will make the msb 0 and the
assembler will be happy. If some_reg is not in bank1, then the msb gets
set and the assembler will complain - which in this case is good.


Scott

On Fri, 26 Apr 2002 10:18:44 -0700 (PDT), Scott Dattalo ####@####.#### wrote:

> a trick from Andy Warren:
> 
>     movf  (some_reg ^ 0x80), w
> 
> If some_reg is in bank1, then the xor will make the msb 0 and the
> assembler will be happy. If some_reg is not in bank1, then the msb gets
> set and the assembler will complain - which in this case is good.

Oh, that's interesting. Thank you.

Is there a way to do that without extra code of the movf? Here is the code
that gpasm is complaining about:

	BSF     STATUS, RP0
	BCF     STATUS, RP1
	BCF	PIE1,TXIE	;disable the interrupt

The first two lines set the proper bits for bank 1 and the third line
accesses a register in bank 1 yet gpasm thinks bank 0 is still active.


-- 
Anthony Tekatch

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.

Anthony Tekatch wrote:
> 
> On Fri, 26 Apr 2002 10:18:44 -0700 (PDT), Scott Dattalo ####@####.#### wrote:
> 
> > a trick from Andy Warren:
> >
> >     movf  (some_reg ^ 0x80), w
> >
> > If some_reg is in bank1, then the xor will make the msb 0 and the
> > assembler will be happy. If some_reg is not in bank1, then the msb gets
> > set and the assembler will complain - which in this case is good.
> 
> Oh, that's interesting. Thank you.
> 
> Is there a way to do that without extra code of the movf? Here is the code
> that gpasm is complaining about:
> 
>         BSF     STATUS, RP0
>         BCF     STATUS, RP1
>         BCF     PIE1,TXIE       ;disable the interrupt
> 
> The first two lines set the proper bits for bank 1 and the third line
> accesses a register in bank 1 yet gpasm thinks bank 0 is still active.
> 
> --
> Anthony Tekatch
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

> 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

On Sat, 27 Apr 2002, Eric Smith wrote:

>                      It's been many years since I did x86 assembly

:). Same here.

> 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

Interesting, but you still have to be careful:


   setbank  1
   clrf     trisa

loop
   setbank  1
   clrf     trisb

   setbank  0
   clrf     porta

   decfsz   count,f
    goto    loop

The "curbank" variable doesn't track the flow. I think to make it work you
need a setbank 1 and a matching setbank 0 in the same linear flow of code.

>
> 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?

This all does sound good. However, I don't think gpasm has enough critical
mass to drive MPASM just yet...

One of the things I plan to do is implement some of this bank switching
stuff in the linker. Specifically, I intend to port the pCode
optimizations I've been writing for SDCC into gplink. Most probably there
will be a set of gpasm specific pragmas to commuincate with the optimizing
linker. That part has not been thought out.

One of the features of the pCode optimizer is that bank selects are
automatically inserted into the code as needed. As a programmer, all you
would need to do is declare a variable and then use and the optimizer will
determine an address for it and switch banks when it's appropriate. Of
course, if you select the address (for example, all SFR addresses are
fixed), then the optimizer can likewise automagically select the proper
bank.

---
One other useful feature would programmable asserts that work with the
simulator. For example, if you know at a certain point in your program
that a specific register must contain a certain value, then it'd be nice
for the simulator to automatically check this for you. For example,


   assert(bank == 1)

   clrf   TRISA

   assert(bank == 0)

   movf   PORTA,W

One of the two instructions above will be accessing the improper bank. The
assert check will catch this. Of course, for this simple contrived
example, the simulator could be instructed to automatically check
banking. However the assert could be used more generically like in C:

   assert(FSR != NULL)

or
   assert( (PCL + index)&0xff > (PCL & 0xff) )  ; make sure not crossing
                                                ; page boundary


Scott

> Interesting, but you still have to be careful:
[...]
> The "curbank" variable doesn't track the flow. I think to make it work
> you need a setbank 1 and a matching setbank 0 in the same linear flow
> of code.

Yes.  The "assume" directive from the x86 world is the same.  It is
unreasonable to expect the assembler to really be able to handle all
cases, since there are lots of ways you might get to a particular
instruction (e.g., computed goto from anywhere, using any instruction
with PCL as the destination).

But it solves the problem of always needing a kludge to avoid or
disable the "wrong bank" warnings from the assembler.  Better to make
those warnings actually do something useful, rather than be something
the programmer must circumvent.

> One other useful feature would programmable asserts that work with the
> simulator.

Yes!!!