[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070919110846.GC15500@Krystal>
Date: Wed, 19 Sep 2007 07:08:46 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: Andi Kleen <andi@...stfloor.org>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
Chuck Ebbert <cebbert@...hat.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 4/7] Immediate Values - i386 Optimization
* Andi Kleen (andi@...stfloor.org) wrote:
> Jeremy Fitzhardinge <jeremy@...p.org> writes:
> >
> > It's a pity that gas seems to generate plain 0x90 nops rather than
> > long-nop forms here. I thought it could do that.
>
> .p2align does it.
>
Sadly, p2align does not apply well to my context. I have to align on 4
bytes boundaries - 1 for the 4 bytes mov, so, if I would use p2align, I
would end up aligning on 4 bytes with p2align and then add 3 bytes
(worse case: adding 3 + 3 = 6 bytes of nops).
However, with the .org arithmetic, I can simply add then quantity of
nops needed to make my alignment on 4 bytes - 1, so the worse case
becomes adding 3 bytes.
The example is:
originally: address & 3 = 1
* p2align
p2align adds 3 bytes to align on 4 bytes boundaries
we add 3 bytes to align on the next 4 bytes - 1, so the immediate value
within the instruction is aligned on 4 bytes boundaries
* org
we add 2 bytes to be aligned on the next 4 bytes - 1.
And yes, it's a pity there is no way to produce the long-nops there. :(
Mathieu
> -Andi
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists