Posted Sep 26, 2013 11:05 UTC (Thu) by etienne (subscriber, #25256)
[Link]
> Wouldn't that break the ABI?
No, instead of reading the 2nd bit of unaligned byte, the compiler emits code to read bit (2+8) of aligned word. Bit stay at the same place.
Good one
Posted Sep 26, 2013 12:56 UTC (Thu) by khim (subscriber, #9252)
[Link]
This will only work for read, not for writes. And even then only if int and not _Bool is used.
Good one
Posted Sep 26, 2013 16:17 UTC (Thu) by deater (subscriber, #11746)
[Link]
One thing not really addressed is how bitfields run opposite ways on little endian and big endian systems.
Not a problem in most cases, but perf_event describes some bitfields
such as struct perf_branch_entry that get written to disk directly.
So if you record a session, then move it to an opposite-endian machine and try to read it back in you have problems.
Good one
Posted Sep 27, 2013 12:05 UTC (Fri) by etienne (subscriber, #25256)
[Link]
> opposite ways on little endian and big endian systems
On my side of the world, you do have little-endian system and BI-endian systems: the processor may be big-endian, but then it always has to interact with at least one little-endian subsystem (could be as simple as a PCI card, more usually most subsystems).
Then, they added stuff at the virtual memory layer to describe that memory mapped area as either little or big endian, which solves a small part of the problem, two bit fields still increment as 0b00, 0b10, 0b01, 0b11.
Then, big endian processor sort of disappeared.
I still prefer:
struct status {
#ifdef LITTLE_ENDIAN
unsigned b1:1, b2:1, b3:1, unused:29;
unsigned xx;
#else
unsigned xx;
unsigned unused:29, b3:1, b2:1, b1:1;
#endif
}
than the 40 equivalent lines of #define, if I have a lot of those status.
