The old compiler didn't care for alignment when accessing an INT type element, whether in packed structs or not. For this reason, I replaced all int type elements in my packed structs by arrays of char and provided macro access to read and write them. The new compiler does exactly the same automatically. With the old compiler, you could accidentally generate word access instructions to an odd memory address, resulting in an effective access to a memory location one byte less. This wasn't even obvious when debugging. And the assembler didn't issue a warning, even if the address was known (constant) at assembly time.
The new compiler definitely does the right thing. Only that it does not (cannot) detect if in some cases the target is aligned and the complex access isn't necessary. Maybe a hint could be placed in the compiler output so the optimizer can detect it and shrink the code if it is sure that the address is aligned. Anyway, the 16bit I/O area isn't there anymore on more recent processors (afaik) and the problem dies out :) But it is a good example why one should be careful with attributes. And with typecasting. (as a hint, the compiler now generates a warning, he didn't before) In case of the AD register which started this thread, the packed attribute was neither necessary nor helpful at all. Same for the volatile qualifier, as an abstract structure type cannot be volatile, only its representation (a variable of that type). JMGross ----- Ursprüngliche Nachricht ----- Von: Wayne Uroda An: GCC for MSP430 - http://mspgcc.sf.net Gesendet am: 30.Oktober.2009 08:35:11 Betreff: Re: [Mspgcc-users] Possible code generation bug for packed structs As far as I know, by putting the packed attribute on struct 'a' you are removing the guarantee that the structure starts at an word aligned address. The address of 'a' isn't known at compile time and so the compiler must generate code that will work at all memory offsets (I think?). How did the compiler behave in the old version?
