bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/20046] x86 feature request: build an instruction including rex


From: hpa at zytor dot com
Subject: [Bug gas/20046] x86 feature request: build an instruction including rex and modr/m
Date: Thu, 05 May 2016 16:26:30 +0000

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]