Bit Manipulation

[Al]

HI,
I'm an hardware designer that HAS to define the software structure for
accessing "my" hardware, so please be patient with me.

Let me put my problem first:
I have "a lot" of "hardware" variables that are non-standard size
(like one, two, seven and so on - bits). What is the best way to work
with them? They MUST be "composed" into 32-bit words before writing
them into the hardware.

Now let me go a little bit more specific:
My first hint was to use a structure of bit-field, but I have some
questions that could not find an answer:
1- Due to portability issues I CANNOT assume that a "group" of bit-
fields summing 32-bits is stored in and int (unsigned)? (I'm correct?)
2- Bit-fields can be viewed as a sub-set of int (?). What if my bit-
field has more bits than the processor defined int? (Example: a bit-
field with 40-bits in a 32-bit machine?) What happens in this
situation?
3- For grouping a set of bit-fields into and unsigned int can I still
use bit-shifting?
4- What happens if I try something like i=255 and I has only 4 bits?
5- The alternatives for bit-field are using simple unsigned int and
perform bit manipulation, but that complicates programming? (Do you
agree?) (Note that 32-bit composing is limited to communication
functions.)


If you have other suggestions that you would like to share I would
appreciate it Very Much.

Thank you for your attention and patience.

 

[santosh]

HI,
I'm an hardware designer that HAS to define the software structure for
accessing "my" hardware, so please be patient with me.

<snip>

Please try comp.arch

 

[Jason Curl]

HI,
I'm an hardware designer that HAS to define the software structure for
accessing "my" hardware, so please be patient with me.

Let me put my problem first:
I have "a lot" of "hardware" variables that are non-standard size
(like one, two, seven and so on - bits). What is the best way to work
with them? They MUST be "composed" into 32-bit words before writing
them into the hardware.

Now let me go a little bit more specific:
My first hint was to use a structure of bit-field, but I have some
questions that could not find an answer:
1- Due to portability issues I CANNOT assume that a "group" of bit-
fields summing 32-bits is stored in and int (unsigned)? (I'm correct?)
2- Bit-fields can be viewed as a sub-set of int (?). What if my bit-
field has more bits than the processor defined int? (Example: a bit-
field with 40-bits in a 32-bit machine?) What happens in this
situation?
3- For grouping a set of bit-fields into and unsigned int can I still
use bit-shifting?
4- What happens if I try something like i=255 and I has only 4 bits?
5- The alternatives for bit-field are using simple unsigned int and
perform bit manipulation, but that complicates programming? (Do you
agree?) (Note that 32-bit composing is limited to communication
functions.)


If you have other suggestions that you would like to share I would
appreciate it Very Much.

You also have to be careful, that if you're using C, the ordering of the
bitfields is implementation defined. We had this problem that by
changing compilers we had to redefine all our structures to keep the
same bit representation.

Why not define an unsigned int (or if using Posix a uint32_t defined by
<inttypes.h>) and define macros to set and clear bits? To keep
portability if you need it (but there'll be a performance cost) don't
use bitfields in a structure but define an API/wrapper that will take a
portable structure and convert it to the bit field you want just before
you write directly to the hardware?