Clyde Smith-Stubbs <clyde@HTSOFT.COM> wrote:
> For the record, I think using "short" for a bit variable, and "long" for
> a 16 bit is a Bad Idea, as is Bytecraft's thing.0 notation for bit access.
> These are unnecessary and confusing.

I agree.  Note that ANSI does provide a means for defining bits: the bit
field.  For instance, if you wanted to directly access bits of INTCON on the
16C71, the compiler should let you do this:

struct intcon
  {
    unsigned int rbif: 1;
    unsigned int intf: 1;
    unsigned int t0if: 1;
    unsigned int rbie: 1;
    unsigned int inte: 1;
    unsigned int t0ie: 1;
    unsigned int adie: 1;
    unsigned int gie: 1;
  };

struct intcon intcon;
#pragma address intcon 0x0b

void main (void)
{
  ...
  intcon.t0if = 0;
  intcon.t0ie = 1;
  intcon.gie = 1;
  ...
}

(Note that I haven't tried this example because I don't have any PIC C
compiler, let alone one that will support bit fields.  So I've probably
made a dumb syntax error somewhere.)

The only non-portable aspect of this is that ANSI doesn't spec which
direction the bits are assigned from (i.e., MSB to LSB or LSB to MSB).
In practice I have not found this to be a problem, as I don't tend to
switch compilers in mid-project.  But two sets of declarations and an
ifdef would fix that problem.

You still don't get pointers to bits, but that is consistent with the C
philosophy of providing operations that are close to the hardware.  If the
hardware provided bit addressing (as was the case on the TMS34010, for
example), then it might be reasonable to have a scalar data type that
mapped to a bit.  In which case sizeof(char) would probably be 8
instead of 1.

Eric