On Tue, 2012-12-18 at 07:28 -0600, Jimi Xenidis wrote:
> On Dec 17, 2012, at 6:26 PM, Peter Bergner <berg...@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.
Peter
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
