----- Ursprüngliche Nachricht ----- Von: Grant Edwards Gesendet am: 17 Apr 2012 21:40:59
On 2012-04-17, JMGross <msp...@grossibaer.de> wrote: >> Access to word members inside a packed struct is NOT done as a word >> read/write, but through a rather complex chainof operation, because >> the alignment of the struct and therefore of the member is unknown. > Why is the alignment of a structure member unkown? > Unless the structure is packed, the alignemnt should be known. You're right, of course. but I was talking about packed structs: >> Access to word members __inside a packed struct__ is NOT done as a word So I was right too :) Actually, now that I think about it, the alignment of fields in packed structures is known as well: bitfields are aligned on bit boundaries, everyting else is aligned to byte boundaries. Von: Grant Edwards Gesendet am: 17 Apr 2012 21:43:10 On 2012-04-17, Grant Edwards <grant.b.edwa...@gmail.com> wrote: >> Unless the structure is packed, the alignemnt should be known. > Actually, now that I think about it, the alignment of fields in packed > structures is known as well: bitfields are aligned on bit boundaries, > everyting else is aligned to byte boundaries. Right again. But the point of my comment was, that for an atomic 16bit read/write operation, the target must be word-aligned. The compiler cannot assume word-alignment for word members in a packed struct, so the access must be done byte-wise and is no longer atomic. Also, even if the struct is not packed, but filtered from a byte-stream (like a serial input buffer), alignment is not ensured. In this case, however, the compiler won't detect this and generate code that leads to a word read from an uneven address, and the CPU will silently ignore the LSB, readin the wrong memory location. To avoid this, I mark all structs that are transmitted through a byte-stream as packed. However, this strays a bit far form the original topic, which was about a push of SR for atomic operations that breaks the stack frame. ----- Ursprüngliche Nachricht ----- Von: William Swanson Gesendet am: 18 Apr 2012 03:36:08 On Tue, Apr 17, 2012 at 7:03 AM, David Brown <da...@westcontrol.com> wrote: >> You have to be particularly careful about read-modify-write codings. >> The msp430 can do some of these actions atomically, but it is possible >> that the compiler will split the actions up. For example, if you write >> "a += 1; b = a" then then compiler might read "a" into a register, do >> the addition, then save the value to "a" as three separate actions, so >> that it can re-use the saved value for "b". > If you declare "a" as "volatile," that will tie the compiler's hands > and force the reads and writes to occur exactly as specified. Any > variable shared between ISR-land and normal code should be "volatile" > to avoid surprises like this. Indeed, it does, but it only means one read, one write. It does not necessarily mean an atomic RMW, so an interrupt may occur in the middle of the operation. Especially if a is a long, which is never atomic. A volatile "a" does not mean that no interrupt may occur that perhaps changes "a" in the middle of the "a+=1" operation or the assignment, leading to unpredictable results. ----- Ursprüngliche Nachricht ----- Von: David Brown Gesendet am: 18 Apr 2012 09:58:12 On 18/04/2012 03:36, William Swanson wrote: >> Any >> variable shared between ISR-land and normal code should be "volatile" >> to avoid surprises like this. > That's okay as a beginner's rule, as you err on the side of caution, but > there are lots of situations when non-volatile variables are more > efficient. You just have to be careful about where and when you force > volatile accesses on the non-volatile variables, or use memory barriers > to ensure everything is done in the required orders. And in case of a 32bit variable, being volatile isn't enough at all. Access must be made atomic, by clearing GIE around the access. This is a bug that is really difficult to track down, as it only appears an interrupt happens right in the middle of reading or writing this variable. Should the compiler auto-generate a GIE clear/restore around access to volatile long or long long variables? Just like it does for HWM operations? JMGross ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
