> On Wed, 24 Jun 1998, Alan Modra wrote:
>
> >On Tue, 23 Jun 1998, Marc Lehmann wrote:
> >
> >> no. could we solve this problem now? 4 byte alignment on pentiums is EVIL
> >> EVIL EVIL. its worse than either zero or 16. Its a total waste of space.
> >
> >Can you prove this claim?
>
> Intel's AP-500: Optimizations for Intel's 32-bit processors says:
> "Prefetcher ... Alignment ... Pentium processor ... don't care"
> (in the chapter 7 table)
>
> Agner Fog's pentopt.txt says:
> "Aligning code is not necessary on the PPlain and PMMX", where PPlain
> means the standard Pentium CPU.
Thanks for posting this info. It does disagree with other Intel documents
though. See for example
http://developer.intel.com/drg/mmx/Manuals/dg/DG_CHP3.HTM
and this extract from "Intel Architecture Optimization Manual" #242816-003
3.4.1 Code
Pentium, Pentium Pro and Pentium II processors have a cache line size
of 32 bytes. Since the prefetch buffers fetch on 16-byte boundaries,
code alignment has a direct impact on prefetch buffer efficiency.
For optimal performance across the Intel Architecture family, it is
recommended that:
· Loop entry labels should be 16-byte aligned when less than eight
bytes away from a 16-byte boundary.
· Labels that follow a conditional branch should not be aligned.
· Labels that follow an unconditional branch or function call should
be 16-byte aligned when less than eight bytes away from a 16-byte
boundary.
> So is there even a single reason why the arch/i386/Makefile uses subject
> line's flags for compiling a pentium kernel? Why not
> -malign-loops=0 -malign-jumps=0 -malign-functions=0 ?
Well, there is a good reason to not supply the -malign options on current
versions of egcs: If not given, egcs will now use the above strategy, ie.
pad code up to a 16-byte boundary if the padding required is 7 bytes or
less.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu