[PATCH v4 3/9] Support APX GPR32 with extend evex prefix
Cui, Lili
lili.cui@intel.com
Thu Jan 4 12:47:05 GMT 2024
> On 26.12.2023 08:00, Cui, Lili wrote:
> >>> --- /dev/null
> >>> +++ b/opcodes/i386-dis-evex-x86-64.h
> >>> @@ -0,0 +1,50 @@
> >>> + /* X86_64_EVEX_0F90 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { VEX_W_TABLE (VEX_W_0F90_L_0) }, },
> >>> + /* X86_64_EVEX_0F91 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { VEX_W_TABLE (VEX_W_0F91_L_0) }, },
> >>> + /* X86_64_EVEX_0F92 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { VEX_W_TABLE (VEX_W_0F92_L_0) }, },
> >>> + /* X86_64_EVEX_0F93 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { VEX_W_TABLE (VEX_W_0F93_L_0) }, },
> >>> + /* X86_64_EVEX_0F38F2 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE (PREFIX_VEX_0F38F2_L_0) }, },
> >>> + /* X86_64_EVEX_0F38F3 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE (PREFIX_VEX_0F38F3_L_0) }, },
> >>> + /* X86_64_EVEX_0F38F5 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE (PREFIX_VEX_0F38F5_L_0) }, },
> >>> + /* X86_64_EVEX_0F38F6 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE(PREFIX_VEX_0F38F6_L_0) }, },
> >>> + /* X86_64_EVEX_0F38F7 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE(PREFIX_VEX_0F38F7_L_0) }, },
> >>> + /* X86_64_EVEX_0F3AF0 */
> >>> + {
> >>> + { Bad_Opcode },
> >>> + { PREFIX_TABLE (PREFIX_VEX_0F3AF0_L_0) }, },
> >>
> >> Am I misremembering that we had agreed that this new file isn't
> >> necessary, by having USE_X86_64_EVEX_FROM_VEX_TABLE handle the
> >> non-64-bit case? At least I couldn't find a mail from you saying this isn't
> possible (and why).
> >>
> > I Prefer not to change the current implement, we need a table that all
> > instructions must go through, it can be x86-64 or len_table, but I think x86-
> 64 is better. It can reuse more old parts of x86-64 (for example
> X86_64_VEX_0F38E*) than len_table. If we use len_table instead, we need to
> let another 18 instructions through the len_table, this will also add the
> number of entries.
> >
> > 18 instructions are:
> > X86_64_VEX_0F38E0~ X86_64_VEX_0F38EF, X86_64_VEX_0F3849, and
> X86_64_VEX_0F384B.
>
> I don't see this as a (necessary) result. Since the patches were (imo
> prematurely) committed already, it'll now be (again) on me to see about
> cleaning up. Oh well.
>
I don't quite understand, I think this modification is a trade-off.
Lili.
More information about the Binutils
mailing list