Peter, I agree that bitfields are a pain. The standards guarantee almost nothing regarding their internal implementation and so there is really no obvious reason to implement what amounts to a hack using them.
While use of the a |= b may generate a single instruction IF b is a constant, it is not guaranteed and in cases where b is an arbitrary expression typically does not. The left side value is read; the expression on the right calculated, the already read left side expression is OR'd in and the the result written. Entering the expression for the right side into a variable prior to ORing is likely to be removed by the compiler optimization so nothing to rely on. Presently I notice that the 4.6.3 version of the compiler I am using accepts bitfield definitions without generating an error. For bitfields defined on a char or unsigned char base type it appears that bits so defined are packed into a 16 bit short word. This is a change from early versions but appears to have occurred well before 2008. This breaks the earlier include files which used to define these as bit fields within an unsigned char object. So legacy code compiles without error but generates an unexpected result. So even if TI provided such files the present bitfield implementation could not use them. Since the C/C++ standards (and most HLLs) generally presume that memory does not change value by itself and that reading from a memory location has no consequence, I/O register access is problematic. The volatile modifier allows handling of the first case of course by demanding that every explicit reference to an identifier in an expression forces an actual read of the associated memory location. [Aside: I wondered if it is allowed to read such a location MORE times than explicitly referenced?]. Rather than trying to hack up the compiler it is probably best to just generate an inline assembly instruction sequence which performs the needed functionality. I use msp430-gcc a lot in my work. I have actually been using an extremely old version of the compiler and discovered the change when I recompiled code (without error) which simply didn't work as before. I can say that I consider this ability to fiddle bits without semaphore protection of every register a huge convenience. Also (and of less concern actually): even though a case has been made that bitfields do not result in efficient code I think it is more that it lends itself to inefficient program design. When I write |= and &= versions of code which duplicate bitfield behavior they result in almost identical code IF you make the code do identical things. So X.bit3 = Y is really X |= (Y & 1) << 3 for example. IF Y is a constant both will result in a single instruction. On 7/23/2012 5:15 AM, Peter Bigot wrote: > While that may or may not have been the understanding of users of > mspgcc during its earlier years, from my experience with GCC's > internals any such an assumption was a mistake. Today, you are far > more likely to have "atomic" RMW instructions if you use the standard > C operators on natural integral types than if you use bitfields. > Bitfields are complex to implement correctly, and gcc introduces > overhead during analysis and optimization to ensure it doesn't violate > the language semantics at a stage when it isn't concerned with > target-specific capabilities. Google for "gcc bitfield" reveals many > examples where this produces hideous code on a variety of targets. > In code with any reasonable level of optimization (-O, -Os), mspgcc > should generate single instruction implementations for & and | on > standard C types wherever supported by the underlying ISA. When it > does not, this is a bug that should be reported so it can be fixed. I > believe other compilers (llvm?) might make other promises, or provide > an alternative solution (such as intrinsics that are guaranteed to > produce bic and bis instructions). I would entertain a proposal to add > such intrinsics. Bitfield structures will be added only if the > definitions are provided by TI in the headers shared among all MSP430 > compilers. > Peter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
