gnupic: Thread: gpasm: res and equates and bitfields

I probably should've sent this just to Craig, but maybe someone else has 
an answer.

I was dabbling around in SDCC trying to figure out why bit variables are
no longer working. One of the problems is that if an 'EQU' directive
contains an expression with a reference to a relocatable object, then the
'first-pass' value is used for the relocatable object when the EQU is
evaluated. I'm not sure if that sentence makes sense, so here's an 
example:


bitfield1	res	1

_bit0	EQU	( (bitfield0<<3)+0)
_bit1	EQU	( (bitfield0<<3)+1)
_bit2	EQU	( (bitfield0<<3)+2)


The idea is that an array of named bits is created and aliased onto the 
byte reserved by the bitfield.


Now, if you write code to access the bits:

    bcf   _bit0 >> 3, _bit0 & 7

gpasm fails to assemble it correctly. The relocatable address used to
evaluate the EQU expressions is not correct.

I suspect this is not easy to fix in gpasm. I do not know if this 
construct works with MPASM (I don't have convenient access to a Window's 
machine with MPLAB installed).

I've used this technique many times for creating bit fields in
absolute-mode code. Does anyone know of a good way of creating bitfields
in relocatable code?

Scott

On Wed, 24 Mar 2004, George M. Gallant wrote:

> Scott,
> 
> Should "bitfield1" and "bitfield0"  be the same?

oops, you're right 

Scott

bitfield0	res	1

_bit0	EQU	( (bitfield0<<3)+0)
_bit1	EQU	( (bitfield0<<3)+1)
_bit2	EQU	( (bitfield0<<3)+2)


The idea is that an array of named bits is created and aliased onto the 
byte reserved by the bitfield.


Now, if you write code to access the bits:

    bcf   _bit0 >> 3, _bit0 & 7

one possible solution

bitfield0	res	1

#define _bit0	bitfield0,0
#define _bit1	bitfield0,1
#define _bit2	bitfield0,2

Now, if you write code to access the bits:

    bcf   _bit0 

On Tue, 2004-03-23 at 23:34, Scott Dattalo wrote:
> I probably should've sent this just to Craig, but maybe someone else has 
> an answer.
> 
> I was dabbling around in SDCC trying to figure out why bit variables are
> no longer working. One of the problems is that if an 'EQU' directive
> contains an expression with a reference to a relocatable object, then the
> 'first-pass' value is used for the relocatable object when the EQU is
> evaluated. I'm not sure if that sentence makes sense, so here's an 
> example:
> 
> 
> bitfield1	res	1
> 
> _bit0	EQU	( (bitfield0<<3)+0)
> _bit1	EQU	( (bitfield0<<3)+1)
> _bit2	EQU	( (bitfield0<<3)+2)
> 
> 
> The idea is that an array of named bits is created and aliased onto the 
> byte reserved by the bitfield.
> 
> 
> Now, if you write code to access the bits:
> 
>     bcf   _bit0 >> 3, _bit0 & 7
> 
> gpasm fails to assemble it correctly. The relocatable address used to
> evaluate the EQU expressions is not correct.
> 
> I suspect this is not easy to fix in gpasm. I do not know if this 
> construct works with MPASM (I don't have convenient access to a Window's 
> machine with MPLAB installed).
> 

It doesn't work with MPASM.  It will generate the "expression is too
complex" error.  This is because the expression can't be reduced to
symbol + offset.

gpasm should generate the same error, but it isn't.  It is because gpasm
evaluates the equ first.  It looks like MPASM is passing the string.

> I've used this technique many times for creating bit fields in
> absolute-mode code. Does anyone know of a good way of creating bitfields
> in relocatable code?
> 

There is no relocation for the bit argument.  So the linker doesn't have
a way to patch the instructions with the bit location.  This means you
have to pass the bit location at assembly time.  The only thing you can
relocate are the bytes.

> Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

On Wed, 24 Mar 2004, scx31114 wrote:

actually I wrote this part:

> bitfield0	res	1
> 
> _bit0	EQU	( (bitfield0<<3)+0)
> _bit1	EQU	( (bitfield0<<3)+1)
> _bit2	EQU	( (bitfield0<<3)+2)
> 
> 
> The idea is that an array of named bits is created and aliased onto the
> byte reserved by the bitfield.
> 
> 
> Now, if you write code to access the bits:
> 
>     bcf   _bit0 >> 3, _bit0 & 7
> 

And scx31114 wrote this part:

> one possible solution
> 
> bitfield0	res	1
> 
> #define _bit0	bitfield0,0
> #define _bit1	bitfield0,1
> #define _bit2	bitfield0,2
> 
> Now, if you write code to access the bits:
> 
>     bcf   _bit0

Well, that does work for the simple case. However, how about this:

; bit add

      bcf     _bit0 >> 3, _bit0 & 7
      movlw   (1 << (_bit0 & 7)
      btfsc   _bit1 >> 3, _bit1 & 7
       xorwf  (_bit0 >> 3),f
      btfsc   _bit2 >> 3, _bit2 & 7
       xorwf  (_bit0 >> 3),f

Here, the bit is being accessed both as a bit and as a 'byte'.

What I really would like is a way of defining a single object to describe 
the bit variable. The only solution that I can think of for relocatable 
code requires two objects to describe a bit variable. You need to know the 
address of the byte containing the bit and the offeset within the byte. 
The byte can be relocated, but the offset is static. 


Scott

Well, that does work for the simple case. However, how about this:

; bit add

      bcf     _bit0 >> 3, _bit0 & 7
      movlw   (1 << (_bit0 & 7)
      btfsc   _bit1 >> 3, _bit1 & 7
       xorwf  (_bit0 >> 3),f
      btfsc   _bit2 >> 3, _bit2 & 7
       xorwf  (_bit0 >> 3),f

Here, the bit is being accessed both as a bit and as a 'byte'.

What I really would like is a way of defining a single object to describe 
the bit variable. The only solution that I can think of for relocatable 
code requires two objects to describe a bit variable. You need to know the 
address of the byte containing the bit and the offeset within the byte. 
The byte can be relocated, but the offset is static. 


Scott


Try this

bitfield0	res	1
bitfield1	res	1
 
_bit0	EQU	0
_bit1	EQU	1
_bit2	EQU	2
....
_bit12  EQU   12

to access the byte
bitfield#v( (_bitN ) /8 )
 
_bitN = _bit0 - _bit999

to access the bit
(_bitN%8) 
or
(_bitN&7)

(ps. you're qmail setup doesn't properly demarcate your replies from the 
quoted text.)

On the discussion of an alternative way for abstractly accessing 
bitfields, scx31114 wrote:

> Try this
> 
> bitfield0	res	1
> bitfield1	res	1
> 
> _bit0	EQU	0
> _bit1	EQU	1
> _bit2	EQU	2
> ....
> _bit12  EQU   12
> 
> to access the byte
> bitfield#v( (_bitN ) /8 )
> 
> _bitN = _bit0 - _bit999
> 
> to access the bit
> (_bitN%8)
> or
> (_bitN&7)

Yes, This works!

For SDCC, it makes sense to write code like:

        BCF     bitfield#v( (_bit4 ) /8 ), (_bit4 & 7)
        MOVLW   1 << (_bit10 & 7)
        XORWF   bitfield#v( (_bit10 ) /8 ),F

For hand written assembly, it'd be nicer to write:

        BCF     bitfield(_bit4), (_bit4 & 7)

Where bitfield is defined to be:

#define bitfield(_bit) bitfield#v( (_bit ) /8 )

This doesn't work (with gpasm at least). As far as I can tell, gpasm 
doesn't fully support the #define directive.

Scott

On Fri, 2004-03-26 at 08:30, Scott Dattalo wrote:
> (ps. you're qmail setup doesn't properly demarcate your replies from the 
> quoted text.)
> 
> On the discussion of an alternative way for abstractly accessing 
> bitfields, scx31114 wrote:
> 
> > Try this
> > 
> > bitfield0	res	1
> > bitfield1	res	1
> > 
> > _bit0	EQU	0
> > _bit1	EQU	1
> > _bit2	EQU	2
> > ....
> > _bit12  EQU   12
> > 
> > to access the byte
> > bitfield#v( (_bitN ) /8 )
> > 
> > _bitN = _bit0 - _bit999
> > 
> > to access the bit
> > (_bitN%8)
> > or
> > (_bitN&7)
> 
> Yes, This works!
> 
> For SDCC, it makes sense to write code like:
> 
>         BCF     bitfield#v( (_bit4 ) /8 ), (_bit4 & 7)
>         MOVLW   1 << (_bit10 & 7)
>         XORWF   bitfield#v( (_bit10 ) /8 ),F
> 
> For hand written assembly, it'd be nicer to write:
> 
>         BCF     bitfield(_bit4), (_bit4 & 7)
> 
> Where bitfield is defined to be:
> 
> #define bitfield(_bit) bitfield#v( (_bit ) /8 )
> 
> This doesn't work (with gpasm at least). As far as I can tell, gpasm 
> doesn't fully support the #define directive.
> 

Your right it doesn't.  There is a bug report on Sourceforge.

> Scott
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>