From: pavenis AT lanet DOT lv
Message-ID: <B0000095702@stargate.astr.lu.lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Date: Thu, 22 Jul 1999 21:43:28 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: .align directives in libc.a
References: <37969AA1 DOT 2B135315 AT cartsys DOT com>
In-reply-to: <Pine.SUN.3.91.990722105443.14732J-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.11)
Reply-To: djgpp-workers AT delorie DOT com

On 22 Jul 99, at 10:55, Eli Zaretskii wrote:

> 
> On Wed, 21 Jul 1999, Nate Eldredge wrote:
> 
> > Eli Zaretskii wrote:
> > > It would be nice if we could finally close this issue
> > > for good, at least until Intel come out with a chip that fetches on
> > > 32-byte boundary ;-)
> > 
> > My AMD K6-3 has 32 byte cache lines (and I think the K6-2 did as
> > well)...
> 
> And the same is true for the Pentium family.
> 
> However, the prefetch queues fetch on 16-byte boundaries, so 16-byte
> alignment is as good as 32-byte, speedwise.  In fact, Intel manuals
> recommend to use the equivalent of ".balign 16,,7" for function entry
> points and targets of jump instructions.  Unfortunately, Andris says
> that it's not simple to make GCC use anything but ".align N" in the
> code it emits.  So we'll probably have to live with some waste, for a
> while.

Perhaps not so difficult. 

But anyway I think it's topic for 3.0. Perhaps getting gcc-2.95 stable
enough is more significant.

Hopefully 
	.p2align  4,,7
should work for gcc (I haven't tested)

But I'm still afraid that without support of 16 byte alignment in 
binutils this all is near to useless.

Andris