gnupic@linuxhacker.org

gnupic@linuxhacker.org


Subject: Re: gputils 11.0 default behavior of Access bit
From: Scott Dattalo
Date: Sat, 22 Mar 2003 21:32:37 -0800 (PST)

On Sat, 22 Mar 2003, Craig Franklin wrote:

<snip>

> If you use current MPASM as the standard, their definition is not wrong,
> but incomplete.  For most registers, the default is 1.
> 
> > However, I know that the default is in fact a=0.
> > 
> 
> For all registers?

 I don't know.

> 
> > So, it might be better to do something like this:
> > 
> >         {
> >           /* If the access bank is not specified, then let the default
> >              value be controlled by 'default_bank_select'
> > 
> >           int a = default_bank_select;
> > 
> >           /* Don't use BSR for special function registers or for
> >              the beginning of memory */
> > 
> >           if (!override_default_BSR && ((file < 0x80) || (file > 0xf7f)) {
> >             a = 0;
> >           }
> > 
> >           ....
> > 
> >         }
> > 
> > Then define a new command line option:
> > 
> >    --default_BSR [0|1]  - if the A bit is not specified in an 18F
> >                           instruction then it's default value can be
> >                           selected here. The default is 0.
> > 
> > Now, there probably should be a warning generated for code like this:
> > 
> > "some_reg" is at address 0x123 which is the second bank.
> > 
> >     MOVF  some_reg,W,A
> > 
> > Here we're saying *not* to use the BSR, yet our register can only be
> > accessed if BSR =1 and we use:
> > 
> > B   EQU   (A^1)
> > 
> >     MOVF  some_reg,W,B
> > 
> > (as an aside, I've toyed with the idea of adding a simulator assertion so
> > that you could write:
> > 
> > 
> >     assert BSR=(some_reg>>8)
> >     movf   some_reg,W,B
> > 
> > )
> > 
> > Scott
> 
> What am I missing?

Nothing. After I sent this, I realized that the 0x80 boundary check (for 
the f452 at least) was sufficient; especially for SFR's. 

> The bit can be assigned a value.  Its seems like a better practice the
> specify it with each instruction.  You wouldn't depend on the default
> value to be "correct".  Or, only specify it when you don't like the
> default that gpasm uses.

I'm not sure if this is compatible with mpasm or not, but it would seem 
that if the b bit is not specified then it's value should be chosen based 
on the address of the register being accessed (like in the code snippet 
above). The only time you'd need to specify 'b' is when you're explicitly 
wishing to override the default behavior. I can't think of an example 
where this would be useful.

Scott


gnupic@linuxhacker.org