Mail Archives: pgcc/2000/01/29/19:05:24
Marc,
thanks.
> While intel recommends relatively large alignments, "common knowledge"
> (linus for example ;) recommends no alignments at all.
> In _my_ tests large alignment is a very very slight win, but in the real
> world, the increased code size might not be worth it (cache effect, long
> nops, AGI because of lea-nops).
> It's a must on 486, though, and a bit better on ppro and later.
This is about loop body alignment, right, not function entry alignment?
I didn't get a clear idea of what you thought about function alignment.
> Yes, -malign-loops=xxx, -malign-functions=xxx etc.. Just read the
> manual(tm).
Oops. I read the man page, really I did. -malign-xxx isn't there,
but it is in the manual (2.8). Thanks, I'll experiment with it.
But there isn't an alignment switch for strings.
> > Admittedly, a cache line is word aligned as well,
> > but wouldn't .align 4 suffice to align to a word boundary?
>
> It depends. The only way data alginment hurts is by wasting space, which
> is rarely a problem (despite cache problems). aligning to a cache line
> helps in practise, although one would think that natural alignment would
> suffice.
It isn't a huge issue, true. But in the kernel, there is no paging.
String pages are pinned in memory. A similar situation arises
in embedded applications.
> Maybe a aligning on longwords is a good trade-off, but that needs
> extensive benchmark data.
Or a switch.
But the .align 4 for egcs seems like a real gaffer to me.
Any idea who I should it to? I've seen mention of it on a newsgroup
when I was researching the problem, so it may be known.
Chris Sears
cbsears AT ix DOT netcom DOT com
- Raw text -