delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/07/07/09:21:58

Sender: root AT delorie DOT com
Message-ID: <37835749.DEDAFC98@inti.gov.ar>
Date: Wed, 07 Jul 1999 10:34:01 -0300
From: salvador <salvador AT inti DOT gov DOT ar>
Organization: INTI
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: es-AR, en, es
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: .align directives in libc.a
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990707151259 DOT 2851D-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019