[PATCH] powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch

Jimi Xenidis jimix at pobox.com
Thu Jan 10 09:19:53 EST 2013

On Dec 18, 2012, at 10:31 AM, Peter Bergner <bergner at vnet.ibm.com> wrote:

> On Tue, 2012-12-18 at 07:28 -0600, Jimi Xenidis wrote:
>> On Dec 17, 2012, at 6:26 PM, Peter Bergner <bergner at vnet.ibm.com> wrote:
>>> Jimi, are you using an "old" binutils from before my patch that
>>> changed the operand order for these types of instructions?
>>>   http://sourceware.org/ml/binutils/2009-02/msg00044.html
>> Actually, this confused me as well, that embedded has the same instruction
>> encoding but different mnemonic.
> The mnemonic is the same (ie, dcbtst), and yes, the encoding is the same.
> All that is different is the accepted operand ordering...and yes, it is
> very unfortunate the operand ordering is different between embedded and
> server. :(
>> I was under the impression that the assembler made no instruction decisions
>> based on CPU.  So your only hint would be that '0b' prefix.
>> Does AS even see that?
> GAS definitely makes decisions based on CPU (ie, -m<cpu> option).  Below is
> the GAS code used in recognizing the dcbtst instruction.  This shows that
> the "server" operand ordering is enabled for POWER4 and later cpus while
> the "embedded" operand ordering is enabled for pre POWER4 cpus (yes, not
> exactly a server versus embedded trigger, but that's we agreed on to
> mitigate breaking any old asm code out there).
> {"dcbtst",	X(31,246),	X_MASK,      POWER4,	PPCNONE,	{RA0, RB, CT}},
> {"dcbtst",	X(31,246),	X_MASK,      PPC|PPCVLE, POWER4,	{CT, RA0, RB}},
> GAS doesn't look at how the operands are written to try and guess what
> operand ordering you are attempting to use.  Rather, it knows what ordering
> it expects and the values had better match that ordering.

I agree, but that means it is impossible for the same .S file can be compiled but -mcpu=e500mc and -mcpu=powerpc?
So either these files have to be Book3S versus Book3E --or-- we use a CPP macro to get them right.
FWIW, I prefer the latter which allows more code reuse.


> Peter

More information about the Linuxppc-dev mailing list