Home Original page

[PATCH] fix dcbt operand order for "server" category

Peter Bergner bergner@vnet.ibm.com
Thu Feb 5 22:36:00 GMT 2009 
On Fri, 2009-02-06 at 08:30 +1030, Alan Modra wrote:
> On Thu, Feb 05, 2009 at 02:29:54PM -0600, Peter Bergner wrote:
> > The dcbt instruction that supports the TH operand used to be optional but
> > now is part of the base ISA.  However, Embdedded and Server categories use
> > different operand ordering, with Embedded having TH being the first operand
> > and Server having TH being the last/3rd operand.  Ditto for dcbtst.
> 
> Horrible.  This patch will break the linux kernel, won't it?

I looked at the GLIBC and Linux kernel source codes, and they seem to
only use the two operand form of the instruction, which should work
with either definition, since TH gets mapped to 0 either way.

Looking at the GCC source code, there is some code Andrew added in
config/rs6000/ppu_intrinsics.h that assumes the "server" order as
defined in the ISA document, meaning TH is the last operand:

  #define __dcbt_TH1000(EATRUNC, D, UG, ID)
    __asm__ volatile ("dcbt %y0,8"
  [snip]

  #define __dcbt_TH1010(GO, S, UNITCNT, T, U, ID)
    __asm__ volatile ("dcbt %y0,10"
  [snip]

How is it that you think it will break the linux kernel?


Hmm, looking again at the linux kernel, it seems the ppc xmon debugger
uses some old binutils code to disassemble the insns and it uses the
embedded operand order:


./arch/powerpc/xmon/ppc-opc.c:{ "dcbtst",  X(31,246), X_MASK,	PPC, { CT, RA, RB } },
[snip]
./arch/powerpc/xmon/ppc-opc.c:{ "dcbt",    X(31,278), X_MASK,	PPC, { CT, RA, RB } },


So what do you think we should do?  Just state that on Linux, we always
use the Embedded operand order regardless of whether we're on a processor
the implements the server category of the ISA?

Peter
More information about the Binutils mailing list