Date:	Wed, 7 Jul 1999 15:14:47 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	salvador <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: .align directives in libc.a
In-Reply-To:	<37820FD4.1F447791@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.990707151259.2851D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 6 Jul 1999, salvador wrote:

> > I don't understand why this is true.  The .text section must be aligned
> > to 16 bytes, which wastes 15 bytes at most, but once .text is 16-byte
> > aligned, any user-defined function can be aligned to 16-byte no matter
> > what the rest of the code does: just emit the ".align" directive.  Or am
> > I missing something?
> 
> I don't know where do you think it can be configured, binutils?

Yes, I was thinking about doing it in Binutils.

> 1) The start of the section is aligned by djgpp.djl

I think djgpp.djl only aligns .data, but .bss and .text aren't
aligned.  But I might be wrong, since I'm not too fluent with the ld
script syntax.

However, if I *am* wrong, I don't understand how come the code and
the data wind up aligned to 4-byte boundary in a running program.

> 2) The aligment of the functions can be controled by -malign-functions

I cannot find a way to cause GCC be smart about -malign-functions.
-malign-functions=4 (i.e. 16-byte alignment) is wasteful and might
actually make the program slower, and I don't see any way of telling
GCC to use something like ".balign 16,,7".  I understand from
explanations by Andris that this is currently impossible without
hacking the compiler sources.  Too bad.

> 3) binutils controls the aligment between .o files (8 currently).

There was a thread some time ago about this, which I think ended up
with a conclusion that the sections are misaligned, and since COFF
aligns relative to the section, we end up with code and some data
which can be aligned or misaligned because of random factors.  This
caused programs compiled with GCC 2.8.1 be slower than compiled with
2.7.2.1.

The user which investigated this told that he reconfigured Binutils to
produce 32-byte alignment for all sections, and the problem went
away.  32-byte alignment is an overkill, I think, but the problem is
evidently very real.

> I think you are talking about (3) and not (2). Is that correct?

What I had in mind was this:

  - set up Binutils to align .text on 16-byte boundary, and .data and
    .bss on 8-byte boundary;
  - align entries into library functions written in assembly with
    ".balign 16,,7"--for those functions where speed is important,
    like memcpy and __dj_movedata;
  - cause GCC to use ".balign 16,,7" in compiled code (which I now
    understand isn't simple to do).

- Raw text -