|

MSP430 gcc - Users

Possible code generation bug for packed structs

View: New views

5 Messages — Rating Filter: Alert me

	Possible code generation bug for packed structs by kavaler :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message A bug (or unfortunate feature) has been added to 3.2.3 version of the compiler related to packed structures. Older versions of the compiler (from 5 years ago) did not show this problem, but the latest CVS version 10/12/2009 does. The problem is that when the packed attribute is applied to a struct the compiler generates very optimal code for accesses to int aligned int variables. Here is a simple test program: struct __attribute__ ((packed)) a { int a; }; struct a aa; void testa() { aa.a \|= 0x8000; } struct b { int b;}; struct b bb; void testb() { bb.b \|= 0x8000; } compiled by: /opt/mspgcc/bin/msp430-gcc -O4 -mmcu=msp430x149 -S mspbug.c yields: .file "mspbug.c" .arch msp430x149 /* Hardware multiplier registers: / __MPY=0x130 __MPYS=0x132 __MAC=0x134 __MACS=0x136 __OP2=0x138 __RESLO=0x13a __RESHI=0x13c __SUMEXT=0x13e .text .p2align 1,0 .global testa .type testa,@function /********************** * Function `testa' **********************/ testa: / prologue: frame size = 0 / .L__FrameSize_testa=0x0 .L__FrameOffset_testa=0x0 / prologue end (size=0) / mov.b &aa, r14 mov #aa+1, r12 mov.b @r12, r13 swpb r13 bis r14, r13 bis #llo(-32768), r13 mov.b r13, &aa swpb r13 mov.b r13, @r12 ret / epilogue: not required / / function testa size 15 (14) / .Lfe1: .size testa,.Lfe1-testa /****** End of function **/ .p2align 1,0 .global testb .type testb,@function /********************* * Function `testb' **********************/ testb: / prologue: frame size = 0 / .L__FrameSize_testb=0x0 .L__FrameOffset_testb=0x0 / prologue end (size=0) / bis #llo(-32768), &bb ret / epilogue: not required / / function testb size 4 (3) / .Lfe2: .size testb,.Lfe2-testb /****** End of function **/ .comm aa,2,2 .comm bb,2,2 /******************************************************************* * File mspbug.c: code size: 19 words (0x13) * incl. words in prologues: 0, epilogues: 2 *********************************************************************/ Notice show the unpacked structure generates one instruction while the packed structure generates 9 instructions to do the same thing. Without the optimizer the 9 instructions grows to 16 instructions. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users
	Re: Possible code generation bug for packed structs by Wayne Uroda-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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? - Wayne -----Original Message----- From: Robert Kavaler [mailto:kavaler@...] Sent: Friday, 30 October 2009 4:35 PM To: mspgcc-users@... Subject: [Mspgcc-users] Possible code generation bug for packed structs A bug (or unfortunate feature) has been added to 3.2.3 version of the compiler related to packed structures. Older versions of the compiler (from 5 years ago) did not show this problem, but the latest CVS version 10/12/2009 does. The problem is that when the packed attribute is applied to a struct the compiler generates very optimal code for accesses to int aligned int variables. Here is a simple test program: struct __attribute__ ((packed)) a { int a; }; struct a aa; void testa() { aa.a \|= 0x8000; } struct b { int b;}; struct b bb; void testb() { bb.b \|= 0x8000; } compiled by: /opt/mspgcc/bin/msp430-gcc -O4 -mmcu=msp430x149 -S mspbug.c yields: .file "mspbug.c" .arch msp430x149 /* Hardware multiplier registers: / __MPY=0x130 __MPYS=0x132 __MAC=0x134 __MACS=0x136 __OP2=0x138 __RESLO=0x13a __RESHI=0x13c __SUMEXT=0x13e .text .p2align 1,0 .global testa .type testa,@function /********************** * Function `testa' **********************/ testa: / prologue: frame size = 0 / .L__FrameSize_testa=0x0 .L__FrameOffset_testa=0x0 / prologue end (size=0) / mov.b &aa, r14 mov #aa+1, r12 mov.b @r12, r13 swpb r13 bis r14, r13 bis #llo(-32768), r13 mov.b r13, &aa swpb r13 mov.b r13, @r12 ret / epilogue: not required / / function testa size 15 (14) / .Lfe1: .size testa,.Lfe1-testa /****** End of function **/ .p2align 1,0 .global testb .type testb,@function /********************* * Function `testb' **********************/ testb: / prologue: frame size = 0 / .L__FrameSize_testb=0x0 .L__FrameOffset_testb=0x0 / prologue end (size=0) / bis #llo(-32768), &bb ret / epilogue: not required / / function testb size 4 (3) / .Lfe2: .size testb,.Lfe2-testb /****** End of function **/ .comm aa,2,2 .comm bb,2,2 /******************************************************************* * File mspbug.c: code size: 19 words (0x13) * incl. words in prologues: 0, epilogues: 2 *********************************************************************/ Notice show the unpacked structure generates one instruction while the packed structure generates 9 instructions to do the same thing. Without the optimizer the 9 instructions grows to 16 instructions. ------------------------------------------------------------------------ ------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users
	Re: Possible code generation bug for packed structs by kavaler :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message The older version generated the same code as if "packed" was not specified. That version was either from 2003 or 2005. I see the justification for doing the byte addressing, but I still think the compiler could generate much better code. For example this: mov.b &aa, r14 mov #aa+1, r12 mov.b @r12, r13 swpb r13 bis r14, r13 bis #llo(-32768), r13 mov.b r13, &aa swpb r13 mov.b r13, @r12 can be reduced to this: bis.b #llo(128), &aa+1 Perhaps when the code to implement the packed attribute was added (or fixed) new peephole optimizations should have been added too. I guess one has to be careful to use "packed" sparingly. Robert > 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? > > - Wayne > > -----Original Message----- > From: Robert Kavaler [mailto:kavaler@di...] > Sent: Friday, 30 October 2009 4:35 PM > To: mspgcc-users@li... > Subject: [Mspgcc-users] Possible code generation bug for packed structs > > A bug (or unfortunate feature) has been added to 3.2.3 version of the > compiler related to packed structures. Older versions of the compiler > (from 5 years ago) did not show this problem, but the latest CVS version > > 10/12/2009 does. The problem is that when the packed attribute is > applied to a struct the compiler generates very optimal code for > accesses to int aligned int variables. Here is a simple test program: > > struct __attribute__ ((packed)) a { int a; }; > struct a aa; > void testa() { aa.a \|= 0x8000; } > > struct b { int b;}; > struct b bb; > void testb() { bb.b \|= 0x8000; } > > compiled by: > /opt/mspgcc/bin/msp430-gcc -O4 -mmcu=msp430x149 -S mspbug.c > > yields: > > .file "mspbug.c" > .arch msp430x149 > > /* Hardware multiplier registers: / > __MPY=0x130 > __MPYS=0x132 > __MAC=0x134 > __MACS=0x136 > __OP2=0x138 > __RESLO=0x13a > __RESHI=0x13c > __SUMEXT=0x13e > > .text > .p2align 1,0 > .global testa > .type testa,@function > /********************** > * Function `testa' > **********************/ > testa: > / prologue: frame size = 0 / > .L__FrameSize_testa=0x0 > .L__FrameOffset_testa=0x0 > / prologue end (size=0) / > > mov.b &aa, r14 > mov #aa+1, r12 > mov.b @r12, r13 > swpb r13 > bis r14, r13 > bis #llo(-32768), r13 > mov.b r13, &aa > swpb r13 > mov.b r13, @r12 > ret > > / epilogue: not required / > / function testa size 15 (14) / > .Lfe1: > .size testa,.Lfe1-testa > /****** End of function **/ > > .p2align 1,0 > .global testb > .type testb,@function > /********************* > * Function `testb' > **********************/ > testb: > / prologue: frame size = 0 / > .L__FrameSize_testb=0x0 > .L__FrameOffset_testb=0x0 > / prologue end (size=0) / > > bis #llo(-32768), &bb > ret > > / epilogue: not required / > / function testb size 4 (3) / > .Lfe2: > .size testb,.Lfe2-testb > /****** End of function **/ > > .comm aa,2,2 > .comm bb,2,2 > > /******************************************************************* > * File mspbug.c: code size: 19 words (0x13) > * incl. words in prologues: 0, epilogues: 2 > *********************************************************************/ > > > Notice show the unpacked structure generates one instruction while the > packed structure generates 9 instructions to do the same thing. Without > the optimizer the 9 instructions grows to 16 instructions. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users
	Re: Possible code generation bug for packed structs by N. Coesel :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message You can steer this behaviour using the packed and aligned attributess. By setting the aligned attribute at 2 the compiler should generate efficient code for elements which are word aligned. ----- Original Message ----- From: "Robert Kavaler" <kavaler@...> To: <mspgcc-users@...> Sent: Friday, October 30, 2009 11:46 AM Subject: Re: [Mspgcc-users] Possible code generation bug for packed structs > The older version generated the same code as if "packed" was not > specified. That version was either from 2003 or 2005. I see the > justification for doing the byte addressing, but I still think the > compiler could generate much better code. For example this: > > mov.b &aa, r14 > mov #aa+1, r12 > mov.b @r12, r13 > swpb r13 > bis r14, r13 > bis #llo(-32768), r13 > mov.b r13, &aa > swpb r13 > mov.b r13, @r12 > > can be reduced to this: > > bis.b #llo(128), &aa+1 > > Perhaps when the code to implement the packed attribute was added (or > fixed) new peephole optimizations should have been added too. I guess > one has to be careful to use "packed" sparingly. > > > Robert > > >> 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? >> >> - Wayne >> >> -----Original Message----- >> From: Robert Kavaler [mailto:kavaler@di...] >> Sent: Friday, 30 October 2009 4:35 PM >> To: mspgcc-users@li... >> Subject: [Mspgcc-users] Possible code generation bug for packed structs >> >> A bug (or unfortunate feature) has been added to 3.2.3 version of the >> compiler related to packed structures. Older versions of the compiler >> (from 5 years ago) did not show this problem, but the latest CVS version >> >> 10/12/2009 does. The problem is that when the packed attribute is >> applied to a struct the compiler generates very optimal code for >> accesses to int aligned int variables. Here is a simple test program: >> >> struct __attribute__ ((packed)) a { int a; }; >> struct a aa; >> void testa() { aa.a \|= 0x8000; } >> >> struct b { int b;}; >> struct b bb; >> void testb() { bb.b \|= 0x8000; } >> >> compiled by: >> /opt/mspgcc/bin/msp430-gcc -O4 -mmcu=msp430x149 -S mspbug.c >> >> yields: >> >> .file "mspbug.c" >> .arch msp430x149 >> >> /* Hardware multiplier registers: / >> __MPY=0x130 >> __MPYS=0x132 >> __MAC=0x134 >> __MACS=0x136 >> __OP2=0x138 >> __RESLO=0x13a >> __RESHI=0x13c >> __SUMEXT=0x13e >> >> .text >> .p2align 1,0 >> .global testa >> .type testa,@function >> /********************** >> * Function `testa' >> **********************/ >> testa: >> / prologue: frame size = 0 / >> .L__FrameSize_testa=0x0 >> .L__FrameOffset_testa=0x0 >> / prologue end (size=0) / >> >> mov.b &aa, r14 >> mov #aa+1, r12 >> mov.b @r12, r13 >> swpb r13 >> bis r14, r13 >> bis #llo(-32768), r13 >> mov.b r13, &aa >> swpb r13 >> mov.b r13, @r12 >> ret >> >> / epilogue: not required / >> / function testa size 15 (14) / >> .Lfe1: >> .size testa,.Lfe1-testa >> /****** End of function **/ >> >> .p2align 1,0 >> .global testb >> .type testb,@function >> /********************* >> * Function `testb' >> **********************/ >> testb: >> / prologue: frame size = 0 / >> .L__FrameSize_testb=0x0 >> .L__FrameOffset_testb=0x0 >> / prologue end (size=0) / >> >> bis #llo(-32768), &bb >> ret >> >> / epilogue: not required / >> / function testb size 4 (3) / >> .Lfe2: >> .size testb,.Lfe2-testb >> /****** End of function **/ >> >> .comm aa,2,2 >> .comm bb,2,2 >> >> /******************************************************************* >> * File mspbug.c: code size: 19 words (0x13) >> * incl. words in prologues: 0, epilogues: 2 >> *********************************************************************/ >> >> >> Notice show the unpacked structure generates one instruction while the >> packed structure generates 9 instructions to do the same thing. Without >> the optimizer the 9 instructions grows to 16 instructions. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users
	Re: Possible code generation bug for packed structs by JMGross :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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? ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mspgcc-users mailing list Mspgcc-users@... https://lists.sourceforge.net/lists/listinfo/mspgcc-users