www.delorie.com/archives/browse.cgi   search  
Mail Archives: pgcc/2000/01/29/11:12:21

Date: Sat, 29 Jan 2000 14:32:45 +0100
From: Marc Lehmann <marc AT gimp DOT org>
To: pgcc AT delorie DOT com
Subject: Re: pgcc and egcs alignment -- function, basic block and string
Message-ID: <20000129143245.F1024@cerebro.laendle>
Mail-Followup-To: pgcc AT delorie DOT com
References: <38921CD6 DOT 2A725779 AT ix DOT netcom DOT com> <20000129032101 DOT A25630 AT atrey DOT karlin DOT mff DOT cuni DOT cz>
Mime-Version: 1.0
In-Reply-To: <20000129032101.A25630@atrey.karlin.mff.cuni.cz>; from hubicka@atrey.karlin.mff.cuni.cz on Sat, Jan 29, 2000 at 03:21:01AM +0100
X-Operating-System: Linux version 2.2.14 (root AT cerebro) (gcc version 2.95.1 19990816 (release))
Reply-To: pgcc AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: pgcc AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Sat, Jan 29, 2000 at 03:21:01AM +0100, Jan Hubicka <hubicka AT atrey DOT karlin DOT mff DOT cuni DOT cz> wrote:
> It is. Consider memset/memcpy/strlen expanders. These can work
> much better when they know that destination is word size aligned.

source you meant ;)

> > documentation has a bug in the .align description saying that the
> I will verify this tommorow and in case you are correct, I will fix this bug.
> (in both gas and gcc).

AFAIK, the problem is that gas acts differently depending on wether
the target is ELF or a.out/COFF. The current gcc (AFAIK again) makes a
test at configure time to find out about that (or maybe it just probes
wether .p2align is available? In the latter case align shouldn't be used,
obviously).

> Again Intel Optimizing Manual recommends this. I believe Intel did some experiments

Well, doing some experiments yourself (as you said) does not hurt
either (if you have a pentium). While intel recommends relatively large
alignments, "common knowledge" (linus for example ;) recommends no
alignments at all.

In _my_ tests large alignment is a very very slight win, but in the real
world, the increased code size might not be worth it (cache effect, long
nops, AGI because of lea-nops).

It's a must on 486, though, and a bit better on ppro and later.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg AT opengroup DOT org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

- Raw text -


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