[PATCH] MIPS EVA ASE Support
Moore, Catherine
Catherine_Moore@mentor.com
Fri Jun 7 21:30:00 GMT 2013
> -----Original Message-----
> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
> Sent: Monday, June 03, 2013 2:22 PM
>
> "Moore, Catherine" <Catherine_Moore@mentor.com> writes:
> > @@ -731,7 +738,7 @@ static const unsigned int mips_isa_table
> > #define INSN_OCTEON2 0x00000100
> >
> > /* Masks used for MIPS-defined ASEs. */
> > -#define INSN_ASE_MASK 0x3c00f0d0
> > +#define INSN_ASE_MASK 0x3c00f0e0
> >
> > /* DSP ASE */
> > #define INSN_DSP 0x00001000
> > @@ -784,7 +791,8 @@ static const unsigned int mips_isa_table
> > #define INSN_LOONGSON_3A 0x00000400
> > /* RMI Xlr instruction */
> > #define INSN_XLR 0x00000020
> > -
> > +/* MIPS32 Enhanced VA Scheme */
> > +#define INSN_EVA 0x00000040
> > /* MCU (MicroController) ASE */
> > #define INSN_MCU 0x00000010
>
> These don't match. The INSN_ASE_MASK line removes 0x10 from the mask
> (which isn't right; that's the INSN_MCU ASE bit) and adds 0x20 (which is
> INSN_XLR, a processor mask).
>
> 0x40 is already in INSN_ASE_MASK and is used by INSN_VIRT64. I'm afraid
> there are no more bits left to claim, so we'll need to do something else.
>
> One way would be to convert the ASE and/or the processor bits to enums,
> like Maciej did with the ISA level, but you'd need to be careful about cases
> where the same instruction is supported by several processor extensions or
> (probably less likely) by several ASEs. Perhaps a simpler alternative would be
> to add a separate ASE field and move all current ASEs to it.
>
Hi Richard,
The MIPS opcode table now has a new ASE field and I've updated the pertinent bits of gas and opcodes to use the new field.
This is an invasive patch. What do you recommend for testing? I've got clean results for mips-elf and mips64-linux. I will post the MIPS EVA support once you have approved this infrastructure change.
Thanks,
Catherine
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ase.cl
Type: application/octet-stream
Size: 1289 bytes
Desc: ase.cl
URL: <https://sourceware.org/pipermail/binutils/attachments/20130607/e6c503d1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ase.patch
Type: application/octet-stream
Size: 212373 bytes
Desc: ase.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20130607/e6c503d1/attachment-0001.obj>
More information about the Binutils
mailing list