gnupic: Thread: Bit variables in C

It's not part of ANSI, but SDCC has support for a `bit' type. This makes sense
if your target MCU is an 8051 (because of the bit instructions). However, how
useful is it for the PIC? I'd personally stay away from it since it is not
portable. OTOH, I'm probably going to keep it in since it's already part of
SDCC. Any opinions?

Scott

Scott Dattalo wrote:
> 
> It's not part of ANSI, but SDCC has support for a `bit' type. This makes sense
> if your target MCU is an 8051 (because of the bit instructions). However, how
> useful is it for the PIC? I'd personally stay away from it since it is not
> portable. OTOH, I'm probably going to keep it in since it's already part of
> SDCC. Any opinions?

yeah, keep 'em... don't know how many times I need a bit flag and find
thm useful over nd over again.

Matt
mail from: dsp systems

Scott Dattalo wrote:
> 
> It's not part of ANSI, but SDCC has support for a `bit' type. This makes sense
> if your target MCU is an 8051 (because of the bit instructions). However, how
> useful is it for the PIC? I'd personally stay away from it since it is not
> portable. OTOH, I'm probably going to keep it in since it's already part of
> SDCC. Any opinions?

Well, it's not quite a bit type, but according to K&R ANSI C does have
support for a bit-field type.  Could this somehow be used in someway to
provide some sort of portability?

Quick synopsis:

struct {
  unsigned int flag_a : 1;
  unsigned int flag_b : 1;
  unsigned int flag_c : 1;
} flags;

This defines a variable 'flags' that contains three 1-bit fields.  I don't
see why it couldn't be used for single 1-bit flags as well.  Perhaps via a
typedef or a macro somehow?

Perhaps I should point out that I am very much still a beginner at coding,
and so may well be talking out my arse here.  So if this isn't possible, I
won't be too surprised. ;)
-- 
Mike Werner  KA8YSD   | He that is slow to believe anything and
                      | everything is of great understanding,
'91 GS500E            | for belief in one false principle is the
Morgantown WV         | beginning of all unwisdom.

On Tue, 14 Nov 2000, Scott Dattalo wrote:
> It's not part of ANSI, but SDCC has support for a `bit' type. This makes sense
> if your target MCU is an 8051 (because of the bit instructions). However, how
> useful is it for the PIC? I'd personally stay away from it since it is not
> portable. OTOH, I'm probably going to keep it in since it's already part of
> SDCC. Any opinions?

I find I usually need lots of single bit flags in typical PIC 
applications, and being able to fit eight of them to a register is
essential to conserve memory. Of course you can just draw up a set of
tables and use explicit bit operations as when hand coding, but it would
be nice if the compiler was able to take care of assigning them
automatically. One problem, how do you represent a pointer to a single bit
variable?

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

On Wed, 15 Nov 2000, Alex Holden wrote:


>                One problem, how do you represent a pointer to a single bit
> variable?

That's a good question. The short answer is I don't know (at least
efficiently). At some point after the pointer has been dereferenced, the FSR
would contain the address of the bit. Bit addresses are different than byte
addresses - or I should say, they map into the byte addresses like so:

 byte address = bit address >> 3


then the desired bit is one of the eight at the byte address: 

specific bit =  ( (*byte_address)>>(bit_address & 3) ) & 1

The shift operation can be done implicitly if the value of bit_address is known
apriori. Unfortunately, if you've got a pointer to it, then you'll have to
explicitly shift. The lower 3 bits of bit_address will be known only at run
time. I do have algorithms for taking a 3-bit number and computing (1<<n), but
it still looks heinous. 

Scott

>
> It's not part of ANSI, but SDCC has support for a `bit' type. This makes
sense
> if your target MCU is an 8051 (because of the bit instructions). However,
how
> useful is it for the PIC? I'd personally stay away from it since it is not
> portable. OTOH, I'm probably going to keep it in since it's already part
of
> SDCC. Any opinions?
>
> Scott
>

I really think it would be nice to have bit sized variables supported by the
compiler.
Perhaps offering a -pedantic or -ansi flag to complain/warn about non-ANSI
code?
I use CCS's PCM, and a quick review of some of the projects I have done
shows that I use bit sized variables extensively.

0x02 cents.

-d

On Wed, 15 Nov 2000, Scott Dattalo wrote:

> On Wed, 15 Nov 2000, Alex Holden wrote:
> 
> 
> >                One problem, how do you represent a pointer to a single bit
> > variable?
> 
> That's a good question. The short answer is I don't know (at least
> efficiently). 

After I wrote this, I tried bit pointers with SDCC. It says:

t.c(21):error *** Array or Pointer to bit|sbit|sfr not allowed.'Pbit'

There, Problem solved!

The PIC code SDCC generates for bit addition is:

bit bit0 = 0;
bit bit1 = 0;
bit bit2 = 0;

  bit1 = bit0 + bit2;  // t.c line 25

;       t.c 25
        movlw   (1 << (_bit1 & 7))
        bcf     (_bit1 >> 3), (_bit1 & 7)
        btfsc   (_bit0 >> 3), (_bit0 & 7)
        xorwf   _bit1,f
        btfsc   (_bit2 >> 3), (_bit2 & 7)
        xorwf   _bit1,f

BTW, I posted a challenge to the PICLIST to minimize this snippit. I'm probably
going to be posting many little challenges like this.


SDCC `bit' types will be supported in the PIC port of SDCC.

Scott

Hello all
> > 
> > >                One problem, how do you represent a pointer to a single bit
> > > variable?
> > 
> > That's a good question. The short answer is I don't know (at least
> > efficiently). 
> 
> After I wrote this, I tried bit pointers with SDCC. It says:
> 
<SNIP>

Hello all,

> > 
> > 
> > >                One problem, how do you represent a pointer to a 
single bit
> > > variable?
> > 
> > That's a good question. The short answer is I don't know (at 
least
> > efficiently). 
> 
> After I wrote this, I tried bit pointers with SDCC. It says:
<snip>

What about bit fields? 
Below is a sample code snippet. they are quire efficient and only 
use a few instructions on most systems, no doublt it could be 
optimised to bsf/bcf instructions.

Code snippet follows............

Bit field definition

typedef struct {
 unsigned char bit7 : 1;
 unsigned char bit6 : 1;
 unsigned char bit5 : 1;
 unsigned char bit4 : 1;
 unsigned char bit3 : 1;
 unsigned char bit2 : 1;
 unsigned char bit1 : 1;
 unsigned char bit0 : 1;
} abyte;


In the code,

abyte *abyteptr;	// Pointer of type abyte
abyte abytestore;

abyteptr = (abyte*) 0x2000  // Point to an address

abytestore = *abyteptr;	    // Read from address

*abyteptr = abytestore;	    // Write to address

Then either use;

abytestore.bit3 = 1 or 0		// TO SET A VALUE

and this to write the byte,

*abyteptr = abytestore;


or 
abyteptr->bit3 = 1 or 0	// To change and store the bit in one go.
-------------------------------------------------------------------------
   "Windows 95 - a 32-bit patch to a 16-bit GUI for an 8-bit operating
    system for a 4-bit processor from a 2-bit company that can't stand
    1-bit of competition."