I am not a compiler expert, but I have been writing embedded software for 8 years now - most of that has been using the msp430 and all of that on mspgcc.
I certainly understand all the arguments being put forth, but I have to say that of the many problems I have encountered over the years, I have not encountered strange or unexpected behavior resulting from use of bitfields for gpio. Nor have I seen anybody access a special function register (such as TACTL) using bitfields - I don't see why you would want to either. I am not saying I know what is best for anyone, but if using bitfields for gpios can make the code more readable and/or more maintainable then I say that is a very important factor. That said, as the products I have worked on have spanned over many different generations and configurations, I find that inline functions can be a better way of providing control for single pins - inline functions such as platformSetLEDRed(...) can contain whatever flavor of code (&= or bitfield) and can also be changed later to invert the input value, should the circuitry attached to the red led change in the future (driving an nfet and then a pfet for example). I am also a firm believer that an embedded engineer should think of their c toolchain as a kind of super-assembler and should inspect the final linked file listing whenever changing things which may affect your code generation, such as CPU variant or even the version of mspgcc. The difference between Port &=! Bit; and Pin = 0; Is large from a readability POV, but they do generate the same code (assigning arbitrary values to a single bit should always be done with caution unless you know what to expect). The argument is similar to that of using macros or not, some may argue they are very powerful, some may argue they are very dangerous, but ultimately if the code works properly, is readable, maintainable and ships on time then everybody wins. - Wayne On 24/07/2012, at 6:24 AM, Peter Bigot <big...@acm.org> wrote: > On Mon, Jul 23, 2012 at 2:49 PM, Paul Voith <p...@voithconsulting.com> wrote: >> 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. > > Yes. I'm confused because, as you note in the previous paragraph, > there's nothing guaranteed about the behavior of bitfields either. So > I'm not seeing what's changed here. As I explain below, I see no > evidence mspgcc ever did anything special here. > >> 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. > > I believe there are situations where you'd need to add the attribute > "packed" to the structure declaration. "packed" is a standard gcc > attribute and is documented in the gcc manual. In other situations > that would not be necessary. > >> 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?]. > > With volatile? No, it's not allowed. > >> 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. > > Can you provide a concrete example? > >> I can say that I >> consider this ability to fiddle bits without semaphore protection of every >> register a huge convenience. > > Sure. But there's nothing about bitfields that makes that more > likely, and some things about them that makes it less likely. > > In my maintenance and evolution of the mspgcc port I haven't seen any > indication that mspgcc ever did anything to enable what you have come > to expect. Certainly there were no traces left by the time mspgcc4 > came into the picture. (There was a horribly grotesque hack intended > to ensure RMW operations on volatiles got translated to single > instructions, but it had nothing to do with bitfields and was > demonstrably broken with complex expressions. I replaced it with a > different solution that has not yet been proven to do anything > incorrect.) > > In short, I can't see why you think the bitfield structures ever > provided the promises you've described. > > With the current version of the compiler, things work pretty reliably > using standard C operations on standard data types, and I've not > encountered any situation where a semaphore protecting a single > register access was necessary. If you have found situations where > things don't work, please file bug reports. > >> 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. > > Yes. gcc translates all bitfield operations into sequences of shifts > and bitwise operations on values in the native word size in the middle > end, long before the target gets a chance to do anything. At best > they're a convenience to users, and at worst introduce extra steps the > compiler has to work around (and sometimes fails to do so). > > Peter > >> 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 ------------------------------------------------------------------------------ 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
