x86: handle immediate operands for .insn
authorJan Beulich <jbeulich@suse.com>
Fri, 31 Mar 2023 06:22:28 +0000 (08:22 +0200)
committerJan Beulich <jbeulich@suse.com>
Fri, 31 Mar 2023 06:22:28 +0000 (08:22 +0200)
commitc032bc4fe7b1bfc29d82e84d39d32557b77aea19
treeaa3bd721537f249a2150bcdecde73a0b26c06683
parente3bf0aade2db023594211b463a156515559fe55f
x86: handle immediate operands for .insn

Since we have no insn suffix and it's also not realistic to infer
immediate size from the size of other (typically register) operands
(like optimize_imm() does), and since we also don't have a template
telling us permitted size(s), a new syntax construct is introduced to
allow size (and signedness) specification. In the absence of such, the
size is inferred from significant bits (which obviously may yield
inconsistent results at least for effectively negative values, depending
on whether BFD64 is enabled), and only if supplied expressions can be
evaluated at parsing time. Being explicit is generally recommended to
users.

Size specification is permitted at bit granularity, but of course the
eventually emitted immediate values will be padded up to 8-, 16-, 32-,
or 64-bit fields.
gas/config/tc-i386-intel.c
gas/config/tc-i386.c
gas/testsuite/gas/i386/insn-32.d
gas/testsuite/gas/i386/insn-32.s
gas/testsuite/gas/i386/insn-64.d
gas/testsuite/gas/i386/insn-64.s