Mail Archives: djgpp-workers/1999/07/04/08:48:42
DJ have said on numerous occasions that 8-byte alignment seems to be
the optimum, and that going further wastes cycles due to the larger
size of memory space.
I'm probably missing something, because I don't understand why would
aligning sections to, say, 16 bytes ``waste cycles''. Aligning a
whole section to the N-byte boundary can only enlarge the memory space
by N-1 bytes at the most, right? So where would that cycle waste come
from?
Aligning sections to higher powers of 2 seems to be a good idea
because COFF cannot record the desired alignment on the symbol level;
every .align directive is relative to the section. So, if we want
programs to access, say, long double variables and large data
structures efficiently, the .data section and the stack need to be
aligned on at least 16-byte boundary, or else no amount of .align
directives in the code will guarantee the proper alignment of such
variables.
The Intel manuals seem to indicate that optimal alignment of code is
also 16 bytes, at least for the targets of call/jmp instructions under
some circumstances. Again, unless the code section is 16-byte
aligned, no clever use of .align by the code will ever be able to
achieve that.
So perhaps we need to make the alignment of data, code and stack
sections be 16 bytes?
And while at that: why does gcc.opt use "-malign-loops=2
-malign-jumps=2 -malign-functions=2" whereas even on 486 the default
is 4?
Btw, does the assembler align the data properly? For example, does it
automatically align a 4-byte int on a 4-byte boundary? If not, why
don't we ever use .align in the .data sections of the assembly sources?
- Raw text -