Re: [RFA] PowerPC VLE port - opcodes update

[Alan Modra <amodra at gmail dot com>]

On Tue, Sep 04, 2012 at 09:35:19AM -0500, Peter Bergner wrote:
> On Sun, 2 Sep 2012 14:07:05 +0930 Alan Modra wrote:
> > On Fri, Aug 31, 2012 at 11:52:53AM +0100, Maciej W. Rozycki wrote:
> > >  The logic to interpret the PPCVLE 
> > > (PPC_OPCODE_VLE) flag should IMHO be changed such that in the VLE mode 
> > > (-mvle) it does not enable any instruction such marked unconditionally.
> > 
> > Agreed.
> 
> Agreed here too, now that Maciej described how VLE works.
> 
> 
> > >  So for example EVADDW would only be enabled whevener -mvle and -mspe are 
> > > used both at the same time, likewise VADDUBS would only work with -mvle 
> > > and -maltivec and with a lone -mvle neither of these instructions would be 
> > > enabled.  The disassembler would work accordingly -- choosing the right 
> > > instruction to dump based on the architecture selected or inferred from 
> > > ELF object flags and the VLE section attribute.
> > 
> > Yes, and of course you can use other -m<cpu>/-M<cpu> options to select
> > the underlying flags.
> 
> I can see two ways to accomplish this.  The first method would be to remove
> the PPCVLE flag from all of the instructions that are possibly valid VLE
> instructions, and rather place the PPCVLE flag in the deprecated field
> of those instructions that will never be valid VLE instructions.  Then the
> normal -mspe, -maltivec, -etc. options can enable the instructions you want.
> This has one drawback, in that as people add new instructions, we may not
> know or remember to add or not add PPCVLE to the deprecated field, so you
> may get new instructions enabled when we shouldn't.
> 
> That leads me to the second option, and that is to copy all of the VLE
> instructions in powerpc_opcodes into vle_opcodes and just use the -mvle
> option to choose between the two structures.  This should allow the
> code to be cleaned up a bit, as we'll never have to look through both
> tables like the code does now.
> 
> I think Alan probably has the final say on how this should be fixed though.

I don't particularly care how this is fixed, but something should be
done.  Peter's second proposal has all the disadvantages associated
with source duplication, but it might be more maintainable so I
slightly favour that idea.  However, I'd be happy with a fix that
leaves the 32-bit insns in the main opcode table.

-- 
Alan Modra
Australia Development Lab, IBM