[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] -fpacked-struct compiler option
|
From: |
Anton Erasmus |
|
Subject: |
Re: [avr-gcc-list] -fpacked-struct compiler option |
|
Date: |
Fri, 07 Jan 2005 16:49:17 +0200 |
On 6 Jan 2005 at 13:19, Ben L. Titzer wrote:
>
> On Jan 6, 2005, at 12:58 PM, E. Weddington wrote:
>
> > Anton Erasmus wrote:
> >
> >> Hi,
> >>
> >> The makefile example that comes with WinAVR uses the
> >> -fpacked-struct compiler option.
> >>
> >> The gcc documentation has the following warning on this option:
> >> Warning: the -fpack-struct switch causes GCC to generate code that
> >> is not binary compatible with code generated without that switch.
> >> Additionally, it makes the code suboptimial. Use it to conform to a
> >> non-default application binary interface.
> >>
> >>
> > 1. We don't have to worry much about "binary compatibility" as AVR
> > projects are compiled into one image, i.e. no loading of external,
> > 3rd party binary images. 2. AFAIK it is only suboptimal on targets
> > that have alignments > 1.
> >
> >> So why is this option used in the example makefile. I would have
> >> thought that with the avr being an 8-bit architecture that
> >> structures would automatically be packed, as there is no advantage
> >> in accessing non-byte alligned data compared to accessing byte
> >> alligned data.
> >>
> >>
> > Um, perhaps just being paranoid? Seemed like a good thing to do at
> > the time? It shouldn't hurt anything to have it in? Anybody have any
> > other reasoning they'd like to throw around? :-)
> >
>
> Many compilers choose to align on the size of the data type, rather on
> the size of the underlying architecture. This is done so that a data
> item that might be larger than a word does not span a cache line
> boundary, which can hurt performance measurably. So for an 8-byte
> quantity like a double precision floating point or long long (on most
> architectures), it is aligned on an 8-byte boundary. Therefore on AVR,
> a 16-bit integer is likely to be aligned on a 2-byte boundary,
> regardless of the fact that the memory is byte addressable and the
> registers are 8 bits (and there is no cache). There are many
> desktop-class assumptions in GCC. They work fairly well for
> desktop-class processors, but really suck when it comes to compiling
> for an 8-bit mcu.
>
Hi,
I ran the following commands on the test code below:
(Lates WinAVR version)
avr-gcc -c test1.c -Os -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -
Wall -Wstrict-prototypes -Wa,-ahlms=test_s.lst
avr-gcc -c test1.c -O1 -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -
Wall -Wstrict-prototypes -Wa,-ahlms=test_1.lst
avr-gcc -c test1.c -O2 -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -
Wall -Wstrict-prototypes -Wa,-ahlms=test_2.lst
avr-gcc -c test1.c -O3 -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -
Wall -Wstrict-prototypes -Wa,-ahlms=test_3.lst
avr-gcc -c test1.c -Os -funsigned-char -funsigned-bitfields -fshort-enums
-Wall -
Wstrict-prototypes -Wa,-ahlms=test1_s.lst
avr-gcc -c test1.c -O1 -funsigned-char -funsigned-bitfields -fshort-enums
-Wall -
Wstrict-prototypes -Wa,-ahlms=test1_1.lst
avr-gcc -c test1.c -O2 -funsigned-char -funsigned-bitfields -fshort-enums
-Wall -
Wstrict-prototypes -Wa,-ahlms=test1_2.lst
avr-gcc -c test1.c -O3 -funsigned-char -funsigned-bitfields -fshort-enums
-Wall -
Wstrict-prototypes -Wa,-ahlms=test1_3.lst
typedef struct
{
unsigned char c;
unsigned long L;
unsigned char b[4];
}test_t;
test_t foo;
void bar(void)
{
volatile unsigned char xx;
volatile unsigned long xxx;
volatile int i;
xx=foo.c;
xxx=foo.L;
i=sizeof(foo);
}
It generates exactely the same code in all cases with no 4 or 2 byte alignment
visible
even without the -fpack-struct option. So it appeard as if the -fpack-struct is
redundent
for the avr. ( On arm-elf-gcc it generates extremely non-optimal code when
using this
option)
GAS LISTING c:\DOCUME~1\anton\LOCALS~1\Temp/ccCmaaaa.s page 1
1 .file "test1.c"
2 .arch avr2
3 __SREG__ = 0x3f
4 __SP_H__ = 0x3e
5 __SP_L__ = 0x3d
6 __tmp_reg__ = 0
7 __zero_reg__ = 1
8 .global __do_copy_data
9 .global __do_clear_bss
10 .text
11 .global bar
12 .type bar, @function
13 bar:
14 /* prologue: frame size=7 */
15 0000 CF93 push r28
16 0002 DF93 push r29
17 0004 CDB7 in r28,__SP_L__
18 0006 DEB7 in r29,__SP_H__
19 0008 2797 sbiw r28,7
20 000a 0FB6 in __tmp_reg__,__SREG__
21 000c F894 cli
22 000e DEBF out __SP_H__,r29
23 0010 0FBE out __SREG__,__tmp_reg__
24 0012 CDBF out __SP_L__,r28
25 /* prologue end (size=10) */
26 0014 3091 0000 lds r19,foo
27 0018 3983 std Y+1,r19
28 001a 2091 0000 lds r18,foo+1
29 001e 3091 0000 lds r19,(foo+1)+1
30 0022 4091 0000 lds r20,(foo+1)+2
31 0026 5091 0000 lds r21,(foo+1)+3
32 002a 2A83 std Y+2,r18
33 002c 3B83 std Y+3,r19
34 002e 4C83 std Y+4,r20
35 0030 5D83 std Y+5,r21
36 0032 89E0 ldi r24,lo8(9)
37 0034 90E0 ldi r25,hi8(9)
38 0036 8E83 std Y+6,r24
39 0038 9F83 std Y+7,r25
40 /* epilogue: frame size=7 */
41 003a 2796 adiw r28,7
42 003c 0FB6 in __tmp_reg__,__SREG__
43 003e F894 cli
44 0040 DEBF out __SP_H__,r29
45 0042 0FBE out __SREG__,__tmp_reg__
46 0044 CDBF out __SP_L__,r28
47 0046 DF91 pop r29
48 0048 CF91 pop r28
49 004a 0895 ret
50 /* epilogue end (size=9) */
51 /* function bar size 38 (19) */
52 .size bar, .-bar
53 .comm foo,9,1
54 /* File "test1.c": code 38 = 0x0026 ( 19), prologues
10, epilogues 9
*/
GAS LISTING c:\DOCUME~1\anton\LOCALS~1\Temp/ccCmaaaa.s
page 2
DEFINED SYMBOLS
*ABS*:00000000 test1.c
*ABS*:0000003f __SREG__
*ABS*:0000003e __SP_H__
*ABS*:0000003d __SP_L__
*ABS*:00000000 __tmp_reg__
*ABS*:00000001 __zero_reg__
c:\DOCUME~1\anton\LOCALS~1\Temp/ccCmaaaa.s:13 .text:00000000 bar
*COM*:00000009 foo
UNDEFINED SYMBOLS
__do_copy_data
__do_clear_bss
Regards
Anton Erasmus
--
A J Erasmus