RE: [arm-gnu] Access to volatile bit-fields
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [arm-gnu] Access to volatile bit-fields
- To: <zakharov@xxxxxxxxxxxx>
- Subject: RE: [arm-gnu] Access to volatile bit-fields
- From: "Ryan Lishman" <ryan@xxxxxxxxxxxxxxx>
- Date: Tue, 31 Aug 2010 10:04:06 +0200
Alexander,
Thanks for your suggestion. There's no 'nice' solution to this. Your macro
approach makes the code a lot prettier, but there's a danger that one may
forget to use it. If there's a possibility that we can get things wrong by
forgetting to use a macro, I'd prefer to avoid bit-fields altogether. The
best I could come up with was a C++ implementation using templates,
something like the following:
typedef unsigned long U32;
template <typename AccessT, U32 Offset, U32 Width> class BitField {
private:
static const U32 mask = (1UL << Width) - 1;
volatile AccessT raw;
public:
inline AccessT& operator= ( const AccessT& val ) volatile
__attribute__((always_inline)) {
AccessT reg = raw;
reg = (reg & ~(mask << Offset)) | ((val & mask) << Offset);
raw = reg;
return (AccessT&)raw;
}
inline operator AccessT() volatile __attribute__((always_inline)) {
return (raw >> Offset) & mask;
}
};
// Example register using bit-field like accesses
union Reg {
BitField<U32, 0,16> halfword;
BitField<U32,16,8> byte;
BitField<U32,24,4> nyb;
BitField<U32,28,2> duo;
BitField<U32,30,1> bit;
};
This allows clean app code that uses the required access width and number of
accesses. The downside is that you have to hack apart existing header files
to define these new bit field unions. Another one is that compiling with
less than -O1 bloats your code a bit.
Not pretty either way ... the best solution would be an ABI compliant
compiler. Anxiously, we wait.
Regards,
Ryan