Are bit-variables in PICC a good idea

[Andras Tantos]

Hi!

I had a discussion in the other day about the usefullness and validity of
the following (non-std) C extension in PICC:

static bit BitVar @ 0x20*8+0;

This would mean that a static variable, named BitVar will be located in the
memory at address 0x20 at bit 0. (Note, that this C compiler is for an 8-bit
microcontroller and this construct should provide a means to define
HW-related functions in C.)

With this declaration the following program would set bit 0 of address 0x20
to 0 and bit 1 to 1:

static bit BitVar1 @ 0x20*8+0;
static bit BitVar2 @ 0x20*8+1;

void main() {
BitVar1 = 0;
BitVar2 = 1;
}

The discussion was about two things:
- Since there are other (though more complex) constructs in standard C to
achieve the same effect, is it a good idea to add a new built-in type
(without the __ prefix) and an address-binding syntax (with the @ operator)
to the language?
- Since all operations on all modern CPUs are work on at least 8-bits of
data at once, is it even possible to compile such a source program into a
valid executable (in a sense that it accesses only memory that's defined in
the source)?

We couldn't on our own reach an agreement so I seek the opinions of a wider
audience.

--
Thanks,
Andras Tantos
<http://andras.tantos.homedns.org>

[Gary Pace]

It really depends on whether your priority is efficiency or portability (or
a compromise between these)
A good technique is to use a typedef based on the platform, something like :

#if __TARGET__ == __SOME_TARGET_WHOSE_COMPILER_SUPPORTS_BITS__
#else
typedef int bit ; /* or is it bit int - I can't remember */
#endif

You can then use the C convention that 0 is false and anything else is true
to make your code portable.

It is almost always a bad idea to define absolute addresses as "magic
numbers" in source code. The link process should give you a much more
maintainable and portable way to do this

"Andras Tantos" <an***********@yahoo.com> wrote in message
news:_U*****************@nwrddc03.gnilink.net...

Hi!

I had a discussion in the other day about the usefullness and validity of
the following (non-std) C extension in PICC:

static bit BitVar @ 0x20*8+0;

This would mean that a static variable, named BitVar will be located in the memory at address 0x20 at bit 0. (Note, that this C compiler is for an 8-bit microcontroller and this construct should provide a means to define
HW-related functions in C.)

With this declaration the following program would set bit 0 of address 0x20 to 0 and bit 1 to 1:

static bit BitVar1 @ 0x20*8+0;
static bit BitVar2 @ 0x20*8+1;

void main() {
BitVar1 = 0;
BitVar2 = 1;
}

The discussion was about two things:
- Since there are other (though more complex) constructs in standard C to
achieve the same effect, is it a good idea to add a new built-in type
(without the __ prefix) and an address-binding syntax (with the @ operator) to the language?
- Since all operations on all modern CPUs are work on at least 8-bits of
data at once, is it even possible to compile such a source program into a
valid executable (in a sense that it accesses only memory that's defined in the source)?

We couldn't on our own reach an agreement so I seek the opinions of a wider audience.

--
Thanks,
Andras Tantos
<http://andras.tantos.homedns.org>

[Jeremy Yallop]

Gary Pace wrote:

typedef int bit ; /* or is it bit int - I can't remember */

The syntax for typedef declarations is the same as for "normal"
declarations. The "typedef" keyword is placed where you might
otherwise place a storage-class specifier such as "static" or
"extern". So,

/* declare an variable `a' of type int */
static int a;

/* declare a type alias `b' for type int */
typedef int b;

/* declare a function `f', which returns a pointer to a function
which returns a pointer to char */
extern char *(*f())();

/* declare a type alias `f' for a function which returns a pointer
to a function which returns a pointer to char */
typedef char *(*f())();

Jeremy.

[Dave Hansen]

On Mon, 12 Jan 2004 02:47:22 GMT, "Andras Tantos"
<an***********@yahoo.com> wrote:

[...]

static bit BitVar1 @ 0x20*8+0;
static bit BitVar2 @ 0x20*8+1; [...]- Since there are other (though more complex) constructs in standard C to
achieve the same effect, is it a good idea to add a new built-in type
(without the __ prefix) and an address-binding syntax (with the @ operator)
to the language?
These are two separate issues:

1) Double-underbar prefix. Keep it. If you (or your user) wants to
hide the "ugliness", use a macro defined in a header a la _Bool and
bool in stdbool.h

2) The only real feature this provides over _Bool is the ability to
specify the location of the bit in memory. And the only reasons to do
this (that I can imagine) are to specify control and status bits in
hardware registers, or to assemble bit masks into bytes or words in
order to handle packages of bits. For both these operations I prefer
masking and shifting operations because the actual operations used and
the order they are taken can be (must be) specified in the code, so
(for example) possible interactions with interrupt service routines
are more visible.

FWIW, I generally avoid bitfield structures except when 1) the
compiler doesn't support a native bit type like _Bool, and 2) I have
several boolean variables I need to define that are not necessarily
related to one another. Something like the following:

struct bits {
unsigned b0 :1;
unsigned b1 :1;
unsigned b2 :1;
unsigned b3 :1;
unsigned b4 :1;
unsigned b5 :1;
unsigned b6 :1;
unsigned b7 :1;
} my_status_bits;

#define boost_switch_position my_status_bits.b0
#define is_warmup_mode my_status_bits.b1
/*etc.*/

But even then, you have to be careful about using these in ISRs.
Something like

is_warmup_mode = TRUE;

isn't generally atomic.

- Since all operations on all modern CPUs are work on at least 8-bits of
data at once, is it even possible to compile such a source program into a
valid executable (in a sense that it accesses only memory that's defined in
the source)?

What's a "modern CPU?"

For the PIC or an 8051, with memory-mapped registers, it makes sense.
For a Pentium running Windoze, it doesn't.

HTH,

-=Dave
--
Change is inevitable, progress is not.