Mail Archives: djgpp-workers/1999/07/07/09:21:58
Eli Zaretskii wrote:
> > 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.
As the stub and headers have a size power of two .text is correctly aligned.
Also crt0 (accidentally) have a size that left the first .o module linked with a
16 bytes aligment. I remmember it because I compiled a version of the benchmarks
with this kind of aligment, the results are included in the pages. (I used some
tricks to avoid the 8 bytes limitation of ld, nothing automatic).
> 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.
? Code is aligned 8 bytes between .o files, between functions that's a gcc
setting so depends on the command line and compile time options of gcc. Data is
aligned 4 bytes because the ints are 4 bytes, but the start of the section is
aligned to a 512 bytes boundary or somethink like it.
> > 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.
Yes is 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,
No sections, that aligment between modules or .o files.
> and the problem went
> away. 32-byte alignment is an overkill, I think, but the problem is
> evidently very real.
Yes, the problem is that:
-------------- first file
functions here
last_address
-------------- next .o file linked by ld
last_address aligned to 8 bytes boundary
functions here
--------------
So if you try to align to 16, 32, etc bytes boundaries you won't succeed. Also:
putting a .align directive at the end of first file doesn't work.
This value is hardcoded in binutils.
> > 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;
But then you'll waste a lot of memory in libc.
> - align entries into library functions written in assembly with
> ".balign 16,,7"--
As in libc each .S is a separated file if you do what you say in the first point
it won't affect anything. What binutils controls is the aligment of the first
byte in a .o file. So this align will be reduced to nothing.
> 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).
Ok.
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
set AT ieee DOT org set-soft AT bigfoot DOT com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
- Raw text -