Date: Wed, 7 Jul 1999 15:14:47 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: salvador cc: djgpp-workers AT delorie DOT com Subject: Re: .align directives in libc.a In-Reply-To: <37820FD4.1F447791@inti.gov.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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).