https://sourceware.org/bugzilla/show_bug.cgi?id=20046
--- Comment #3 from hpa at zytor dot com <hpa at zytor dot com> --- I thought about it some more, and a better choice that .rex[/w] would be something like .inspfxs[bwlq] <r>,<m> that would be able to generate 66, 67, or REX prefixes as appropriate. The possible combinations would be: <r> can be a register or an immediate in the range 0-7. If it is a register, it sets the default operand size. If a register, it controls REX.R for .inspfxs. <m> can be a register or a memory operand. If it is a register, it sets the default operand size. If a register, it controls REX.B; if a memory operand it controls REX.B and REX.X for .inspfxs. If neither <r> nor <m> is a register, and the memory operand isn't size-specified with the PTR argument (in Intel syntax), then [bwlq] has to be provided to the .inspfxs operation, (as with any other instruction). It doesn't matter for .modrm, of course. b - no 66 prefix nor REX.W in any mode w - 66 prefix in 32- or 64-bit mode l - 66 prefix in 16-bit mode q - REX.W (only valid in 64-bit mode) A 67 prefix would be generated if appropriate for the memory operand. .vex and .evex pseudo-ops could be added as well. However, scaled SIB and all the various EVEX modes would make that much more complicated. It is unlikely we would use those in the Linux kernel, but there might be user-space programs that might be interested. I would suggest treating that as a potential future extension if it turns out to be desirable. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
