Date: Wed, 28 Apr 1999 14:42:11 +0100
From: cmatraki AT ee DOT ucl DOT ac DOT uk (Chris Matrakidis)
Message-Id: <199904281342.OAA12455@melchard.ee.ucl.ac.uk>
To: djgpp-workers AT delorie DOT com
Subject: Re: [dma AT hpesdma DOT fc DOT hp DOT com: Performance Observation]
X-Sun-Charset: US-ASCII
Reply-To: djgpp-workers AT delorie DOT com

> This means that the code produced by GCC 2.7.2.x will sometimes run 
> faster and sometimes slower that the code of 2.8.1, since the actual 
> alignment is determined by pseudo-random factors, right?

Yes. The way I understand it, with djgpp 2.02 the following is true:
gcc 2.7.2, .bss double aligned, .data not double aligned.
gcc 2.8.1, .bss not double aligned, .data double aligned.


> Is the problem limited to .bss data?

The problem is also present in the .data section.
Probably the .text section has the same problem as well, but I didn't try it.


> 
> > I can't think of any easy way to overcome this.
> 
> Can't we change the alignment parameter in Binutils configuration?
>

I thought of that as well, and found a discussion of it in the list from last
October. So I rebuilt binutils with a defult section alignment of 32 bytes.
Now both gcc 2.7.2 and 2.8.1 give comparable results, and all sections are
properly aligned.

I'm not sure whether 32-byte alignment is the best option, but the waste
seemed reasonable and SET said in that old thread that this will give better
results in some cases.

Another related question is, what is the guaranteed alignment from malloc?
A quick test shows that malloc (from 2.02) does return double aligned memory,
but I'm not certain whether this is always true.