Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Fri, 07 Feb 2014 09:57:19 -0800

Shudder again.

I recommend a look at the c99 standard (6.7.2.1; paragraph 10)

An implementation may allocate any addressable storage unit large

enough to hold a bit-

field. If enough space remains, a bit-field that immediately follows

another bit-field in a

structure shall be packed into adjacent bits of the same unit. If

insufficient space remains,

whether a bit-field that does not fit is put into the next unit or

overlaps adjacent units is

implementation-defined. The order of allocation of bit-fields within a

unit (high-order to

low-order or low-order to high-order) is implementation-defined. The

alignment of the

addressable storage unit is unspecified.

Hence any assumption about what storage unit the compiler uses, how

adjacent bits

are packed across a storage-unit boundary and in what order bits are

allocated

(LSB->MSB or MSB->LSB) is *not*portable*. This may change from compiler

to compiler

- even from one version to another.

IMHO it is not a good idea to use bitfields the way the motor code does

(i.e.,

making assumptions about their layout). You can find a lot of

discussions on the

subject in the forums.

- Till

PS:

Just for illustration of the point:

struct A {
   unsigned long  a1: 24;
   unsigned long  a2: 24;
   unsigned short a3: 16;
};

is stored (by gcc-4.7.3) into 3 32-bit words (i386) or one 64-bit word

(x86_64),

respectively.

Another one: the same gcc packs bitfields together differently

(admittedly in

a way we'd expect it to do it) depending on whether we use chars or shorts:

union BF4 {
    struct {
        unsigned char a: 4;
        unsigned char b: 8;
    } charfield;
    struct {
        unsigned short a: 4;
        unsigned short b: 8;
    } shortfield;
};

int
main()
{
union BF4 bf;
    printf("Sizeof union:      %i\n",  sizeof(bf));
    printf("Sizeof charfield:  %i\n", sizeof(bf.charfield));

 printf("Sizeof shortfield: %i\n", sizeof(bf.shortfield));

memset(&bf, 0, sizeof(bf));

    /* set 'a' via charfield */
    bf.charfield.a = 0xf;
    /* read-back as shortfield */
    printf("0x%1x  -- expected 0xf\n", bf.shortfield.a);
    memset(&bf, 0, sizeof(bf));
    /* set 'b' via charfield */
    bf.charfield.b = 0xff;
    /* read-back as shortfield */
    printf("0x%1x -- expected 0xff\n", bf.shortfield.b);
}.4)

However: the point is that there is no *guarantee* for a particular layout.
Search the gcc documentation for '-Wpacked-bitfield-compat' for a case
where the layout changed between gcc versions (around 4.4).

On 02/07/2014 07:56 AM, Ron Sluiter wrote:

On 2/7/2014 9:21 AM, [email protected] wrote:

I suggest to remove the switch and replace the occurrence of  MSB_First with the EPICS provided endianness switch:
+#include <epicsEndian.h>

-#ifdef MSB_First
+#if (EPICS_BYTE_ORDER == EPICS_ENDIAN_BIG)

Thanks for the suggestion but MSB_First/LSB_First is set to indicate how
C/C++ bit fields are packed, not endianness.
What compiler and compiler version are you using?

Ron

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System