mtsprg on BOOKE

mtsprg on BOOKE

[Jeff Baker]

Why does the following assembly produce errors on BOOKE?

mtsprg 7, %r3
mfsprg %r3, 7

Doesn't BOOKE have SPRG0-0 -> SPRG0-7?

Re: mtsprg on BOOKE

[Jeff Baker]

Whoops, I mean SPRG0->SPRG7 obviously.

Jeff Baker wrote:
> Why does the following assembly produce errors on BOOKE?
> 
> mtsprg 7, %r3
> mfsprg %r3, 7
> 
> Doesn't BOOKE have SPRG0-0 -> SPRG0-7?

RE: mtsprg on BOOKE

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Jeff Baker
> Sent: 29 October 2004 17:19

> 
> Whoops, I mean SPRG0->SPRG7 obviously.
> 
> Jeff Baker wrote:
> > Why does the following assembly produce errors on BOOKE?
> > 
> > mtsprg 7, %r3
> > mfsprg %r3, 7
> > 
> > Doesn't BOOKE have SPRG0-0 -> SPRG0-7?

  Just a WAG, but you didn't forget the -mregnames flag by any possible
chance, did you?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: mtsprg on BOOKE

[Jeff Baker]

-mregnames has no effect.

Dave Korn wrote:
>>-----Original Message-----
>>From: binutils-owner On Behalf Of Jeff Baker
>>Sent: 29 October 2004 17:19
> 
> 
>>Whoops, I mean SPRG0->SPRG7 obviously.
>>
>>Jeff Baker wrote:
>>
>>>Why does the following assembly produce errors on BOOKE?
>>>
>>>mtsprg 7, %r3
>>>mfsprg %r3, 7
>>>
>>>Doesn't BOOKE have SPRG0-0 -> SPRG0-7?
> 
> 
>   Just a WAG, but you didn't forget the -mregnames flag by any possible
> chance, did you?
> 
>     cheers, 
>       DaveK

Re: mtsprg on BOOKE

[James E Wilson]

On Fri, 2004-10-29 at 09:17, Jeff Baker wrote:
> Why does the following assembly produce errors on BOOKE?
> mtsprg 7, %r3

Looking at the sources, opcode/ppc-opc.c, I see that the mtsprg macro
only takes 2-bit sprg register numbers, which is apparently correct for
the basic ppc architecture, but not for e500.  This should probably be
conditional on the architecture choice.  I haven't looked at any
architecture or processor manuals to double check.

Meanwhile, "mtsprg7 %r3" will work.  Likewise for mfsprg.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: mtsprg on BOOKE

[Jeff Baker]

I've never worked in the opcodes area before and I'm not sure how to 
implement this change.  Can anyone give me a hand?

James E Wilson wrote:
> On Fri, 2004-10-29 at 09:17, Jeff Baker wrote:
> 
>>Why does the following assembly produce errors on BOOKE?
>>mtsprg 7, %r3
> 
> 
> Looking at the sources, opcode/ppc-opc.c, I see that the mtsprg macro
> only takes 2-bit sprg register numbers, which is apparently correct for
> the basic ppc architecture, but not for e500.  This should probably be
> conditional on the architecture choice.  I haven't looked at any
> architecture or processor manuals to double check.
> 
> Meanwhile, "mtsprg7 %r3" will work.  Likewise for mfsprg.

Re: mtsprg on BOOKE

[Kumar Gala]

Jeff,

Looking at opcode/ppc-opc.c I think what you want to look at modifying 
the following:

\f
/* The operands table.

    The fields are bits, shift, insert, extract, flags.

    We used to put parens around the various additions, like the one
    for BA just below.  However, that caused trouble with feeble
    compilers with a limit on depth of a parenthesized expression, like
    (reportedly) the compiler in Microsoft Developer Studio 5.  So we
    omit the parens, since the macros are never used in a context where
    the addition will be ambiguous.  */

.... [snip] ....

   /* The SPRG register number in an XFX form m[ft]sprg instruction.  */
#define SPRG SPRBAT + 1
#define SPRG_MASK (0x3 << 16)
   { 2, 16, NULL, NULL, 0 },

-- 

You will want to grow the size of the field from 2 bits to 3.  I can 
remember if you will need to adjust the shift amount or not.  I would 
also recommend adding some testcases to gas/testsuite/ppc/booke.{s,d}

- kumar

On Nov 1, 2004, at 9:26 AM, Jeff Baker wrote:

> I've never worked in the opcodes area before and I'm not sure how to
> implement this change.  Can anyone give me a hand?
>
> James E Wilson wrote:
>  > On Fri, 2004-10-29 at 09:17, Jeff Baker wrote:
>  >
> >>Why does the following assembly produce errors on BOOKE?
>  >>mtsprg 7, %r3
>  >
> >
> > Looking at the sources, opcode/ppc-opc.c, I see that the mtsprg macro
>  > only takes 2-bit sprg register numbers, which is apparently correct 
> for
>  > the basic ppc architecture, but not for e500.  This should probably 
> be
>  > conditional on the architecture choice.  I haven't looked at any
>  > architecture or processor manuals to double check.
>  >
> > Meanwhile, "mtsprg7 %r3" will work.  Likewise for mfsprg.

Re: mtsprg on BOOKE

[James E Wilson]

On Mon, 2004-11-01 at 07:26, Jeff Baker wrote:
> I've never worked in the opcodes area before and I'm not sure how to 
> implement this change.  Can anyone give me a hand?

Find the mtsprg entry in the opcodes/ppc-opc.c file.

Most ports do a sequential search, and take the first matching entry. 
So you can add a second mtsprg entry immediately before the existing
one, where this additional entry is only enabled for booke (and
ppc405?).  You will need to adjust the masks and operand bits as
appropriate.  You can't change the definition of existing macros, but
you can add new ones that are correct for the booke case, and use them
in this new entry.

Some targets use operand specifiers that are interpreted by the
assembler.  In this case, you can modify e.g. config/tc-ppc.c to
interpret the operand specifier differently depending on the
architecture.  The PPC port does not appear to use this scheme though. 
So it looks like we have to modify the opcodes/ppc-opc.c file directly.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: mtsprg on BOOKE

[Jeff Baker]

Thanks, I figured out how to get this working... sortof.  I can change 
the generic SPRG/SPRG_MASK definitions as a quick test so I know I'm 
making the correct modification, but I don't know how to define the 
mfsprg and mtsprg ops in such a way as it won't complain about duplicate 
insns.

James E Wilson wrote:
> On Mon, 2004-11-01 at 07:26, Jeff Baker wrote:
> 
>>I've never worked in the opcodes area before and I'm not sure how to 
>>implement this change.  Can anyone give me a hand?
> 
> 
> Find the mtsprg entry in the opcodes/ppc-opc.c file.
> 
> Most ports do a sequential search, and take the first matching entry. 
> So you can add a second mtsprg entry immediately before the existing
> one, where this additional entry is only enabled for booke (and
> ppc405?).  You will need to adjust the masks and operand bits as
> appropriate.  You can't change the definition of existing macros, but
> you can add new ones that are correct for the booke case, and use them
> in this new entry.
> 
> Some targets use operand specifiers that are interpreted by the
> assembler.  In this case, you can modify e.g. config/tc-ppc.c to
> interpret the operand specifier differently depending on the
> architecture.  The PPC port does not appear to use this scheme though. 
> So it looks like we have to modify the opcodes/ppc-opc.c file directly.

Re: mtsprg on BOOKE

[James E Wilson]

On Tue, 2004-11-02 at 07:34, Jeff Baker wrote:
> Thanks, I figured out how to get this working... sortof.  I can change 
> the generic SPRG/SPRG_MASK definitions as a quick test so I know I'm 
> making the correct modification, but I don't know how to define the 
> mfsprg and mtsprg ops in such a way as it won't complain about duplicate 
> insns.

I am not intimately familiar with the ppc port, so I don't know offhand
what criteria is uses to say that two entries are duplicate
instructions.  I suggest looking at or debugging the result to find out.

I was assuming you could have two entries with the same instruction
name, as there are examples of that, e.g. mtdbsr, but maybe that works
only if they are enabled for different processors.  In that case, we
would need booke and ppc-booke for the mtsprg entries, but there is
probably no current way to specify ppc minus booke.  In that case, we
may need one entry, but then there is the question of how to
conditionalize it, as I don't think you can specify variable size
fields, but we do need to give a warning if someone tries to access
sprg7 with a basic ppc target.  I think you can fix that problem with
accessor functions.  See for instance insert_spr/extract_spr.  So you
can define insert_sprg/extract_sprg functions, you can specify the
maximum bit-field size for the argument, and then inside the insert_sprg
function you can give an error if a register is used that is out of
range for the current architecture.  See for instance the insert_bo and
valid_bo functions which do something like this.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com