Re: [PATCH] Lexra support in binutils

[Thiemo Seufer <ths at networkno dot de>]

Adam Nemet wrote:
> Thiemo Seufer writes:
> > Adam Nemet wrote:
> > > Right so did I but isn't the "formula":
> > > 
> > >   mips64r2 - MIPS unaligned instructions + custom unaligned instructions = mips64r1.9?
> > 
> > Anything without MIPS unaligned instructions would be mips0.9. I vaguely
> > (mis-?)remembered some octeon coprocessor instruction are different, too,
> > so I came up with mips0.8 for octeon.
> 
> Right.  It's only an omission (certain cop2 instructions are not implemented).
> Note that these instructions can be selectively implemented by processors so
> defining an new ISA for each combination may not scale that well.  (Hence was
> my idea to create a way for a processor to be defined not just in terms of an
> ISA + processor-specific instruction but also in terms of processor-specific
> omissions.)

Agreed, differences in COP2 which is largely unspecified anyway don't
justify an additional pseudo-ISA.

> > Custom instructions of any sort would be processor specific, not
> > part of an (Pseudo-)ISA. From that POV, the octeon would be a
> > mips0.8 + mips2 + mips3 + mips4 + mips64 + mips64r2 + octeon
> > part.
> 
> Sure but my question was targeted at the *ISA* that this "other" octeon would
> be derived from.  To avoid any misunderstanding, is this approximately what
> you're proposing?:

[snip]
> @@ -539,7 +541,10 @@ struct mips_opcode
>     (mips_isa_table[(Y & INSN_ISA_MASK) - 1] >> ((X & INSN_ISA_MASK) - 1)) & 1
>     is non-zero.  */
>  static const unsigned int mips_isa_table[] =
> -  { 0x0001, 0x0003, 0x0607, 0x1e0f, 0x3e1f, 0x0a23, 0x3e63, 0x3ebf, 0x3fff };
> +  { 0x0001, 0x0003, 0x0607, 0x1e0f, 0x3e1f, 0x0a23, 0x3e63, 0x3ebf,
> +    /* Add INSN_ISA64R2_0_9 here: INSN_ISA0_8 + INSN_ISA2 ... + INSN_ISA64R2  */
> +    0x....,
> +    0x3fff };

Oh I see. I always had the vague feeling this clever trick would bite
use some day. :-) Yes, it should be something like that, probably with
applying Maciej's namespace observation: {ISA,INSN}_ISA63R2 instead of
the unwieldy {ISA,INSN}_ISA64_0_9.


Thiemo