Re: [RFA] PowerPC VLE port - opcodes update

[Peter Bergner <bergner at vnet dot ibm dot com>]

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.

Peter