Mail Archives: djgpp-workers/1999/07/04/11:33:21
> I'm probably missing something, because I don't understand why would
> aligning sections to, say, 16 bytes ``waste cycles''.
Imagine a ridiculous degenerate case: You have 16 one-byte functions,
all of which are called. If you pack them, you trigger only one
16-byte cache miss. If you align them to 16-byte boundaries, you
trigger 16 16-byte cache misses. Padding makes your program bigger,
so the average total number of cache misses goes up. The trick is to
defer those misses to places where performance isn't as critical.
> So perhaps we need to make the alignment of data, code and stack
> sections be 16 bytes?
We can align text to 16 and data to 8 if we want.
> 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?
I think that's what Linux used at the time; it reduces the footprint
of the runtime. I'm open to other values if they make sense.
> 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?
You shouldn't need to align anything in an asm file, because you
*know* the alignment already - it's strictly based on what things
you've defined in the file so far. You need .align inside functions
or at the beginning of functions that aren't the first functions
because it's so hard to pre-determine the sizes of functions, so gcc
just .aligns *all* functions, and we may have just cut-n-pasted that
into our .s files.
You *can* .align data if you want to be lazy and still ensure proper
alignment, but the assembler won't do it for you.
- Raw text -