aboutsummaryrefslogtreecommitdiff
path: root/opcodes
AgeCommit message (Collapse)AuthorFilesLines
2022-09-23RISC-V: Add Zawrs ISA extension supportChristoph Müllner1-0/+4
This patch adds support for the Zawrs ISA extension ("wrs.nto" and "wrs.sto" instructions). The specification can be found here: https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head MemPair vendor extensionChristoph Müllner1-0/+24
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadMemPair extension, a collection of T-Head specific two-GP-register memory operations. The 'th' prefix and the "XTheadMemPair" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add support for literal instruction argumentsChristoph Müllner1-0/+9
This patch introduces support for arbitrary literal instruction arguments, that are not encoded in the opcode. A typical use case for this feature would be an instruction that applies an implicit shift by a constant value on an immediate (that is a real operand). With this patch it is possible to make this shift visible in the dissasembly and support such artificial parameter as part of the asssembly code. Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head MemIdx vendor extensionChristoph Müllner1-0/+60
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadMemIdx extension, a collection of T-Head specific GPR memory access instructions. The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR for the RISC-V toolchain conventions ([1]). In total XTheadCmo introduces the following 44 instructions (BU,HU,WU only for loads (zero-extend instead of sign-extend)): * {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2 * {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 * {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2 [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head FMemIdx vendor extensionChristoph Müllner1-0/+10
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadFMemIdx extension, a collection of T-Head-specific floating-point memory access instructions. The 'th' prefix and the "XTheadFMemIdx" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head MAC vendor extensionChristoph Müllner1-0/+8
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadMac extension, a collection of T-Head-specific multiply-accumulate instructions. The 'th' prefix and the "XTheadMac" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head CondMov vendor extensionChristoph Müllner1-0/+4
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadCondMov extension, a collection of T-Head-specific conditional move instructions. The 'th' prefix and the "XTheadCondMov" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head Bitmanip vendor extensionChristoph Müllner1-0/+17
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of T-Head-specific bitmanipulation instructions. The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add support for arbitrary immediate encoding formatsChristoph Müllner1-0/+34
This patch introduces support for arbitrary signed or unsigned immediate encoding formats. The formats have the form "XsN@S" and "XuN@S" with N being the number of bits and S the LSB position. For example an immediate field of 5 bytes that encodes a signed value and is stored in the bits 24-20 of the instruction word can use the format specifier "Xs5@20". Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head SYNC vendor extensionChristoph Müllner1-0/+7
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadSync extension, a collection of T-Head-specific multi-processor synchronization instructions. The 'th' prefix and the "XTheadSync" extension are documented in a PR for the RISC-V toolchain conventions ([1]). [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22RISC-V: Add T-Head CMO vendor extensionChristoph Müllner1-0/+25
T-Head has a range of vendor-specific instructions. Therefore it makes sense to group them into smaller chunks in form of vendor extensions. This patch adds the XTheadCmo extension, a collection of T-Head specific cache management operations. The 'th' prefix and the "XTheadCmo" extension are documented in a PR for the RISC-V toolchain conventions ([1]). In total XTheadCmo introduces the following 21 instructions: * DCACHE.{C,CI,I}ALL * DCACHE.{C,CI,I}{PA,VA,SW} rs1 * DCACHE.C{PAL1,VAL1} rs1 * ICACHE.I{ALL,ALLS} * ICACHE.I{PA,VA} rs1 * L2CACHE.{C,CI,I}ALL Contrary to Zicbom, the XTheadCmo instructions don't have a constant displacement, therefore we have a different syntax for the arguments. To clarify this is intended behaviour, there is a set of negative test for Zicbom-style arguments in x-thead-cmo-fail.s. [1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19 v2: - Add missing DECLARE_INSN() list - Fix ordering Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2022-09-22opcodes: SH fix bank register disassemble.Yoshinori Sato2-0/+7
* sh-dis.c (print_insn_sh): Enforce bit7 of LDC Rm,Rn_BANK and STC Rm_BANK,Rn is always 1.
2022-09-22RISC-V: Remove "b" operand type from disassemblerTsukasa OI1-1/+0
There are a few operand types not used by any RISC-V instructions. - Cx - Vf - Ve - [ - ] - b But most of them has a reasoning to keep them: - Cx : Same as "Ct" except it has a constraint to have rd == rs2 (similar to "Cw"). Although it hasn't used, its role is clear enough to implement a new instruction with this operand type. - Vf, Ve : Used by vector AMO instructions (not ratified and real instructions are not upstreamed yet). - [, ] : Unused tokenization symbols. Reserving them is not harmful and a vendor may use this symbol for special purposes. ... except "b". I could not have found any reference to this operand type except it works like the "s" operand type. Historically, it seems... it's just unused from the beginning. Its role is not clear either. On such cases, we should vacate this room for the new operand type with much clearer roles. opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Remove 'b' operand type.
2022-09-14bfd: Stop using -Wstack-usage=262144 when built with ClangTsukasa OI1-0/+18
Some components of GNU Binutils will pass "-Wstack-usage=262144" when "GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage", despite that related configuration part in bfd/warning.m4 handles the latest Clang (15.0.0 as of this writing) as "GCC >= 5.0". The option "-Wstack-usage" was ignored when the first version of Clang is released but even this "ignoring" behavior is removed before Clang 4.0.0. So, if we give Clang "-Wstack-usage=262144", it generates a warning, making the build failure. This commit checks "__clang__" macro to prevent adding the option if the compiler is identified as Clang. bfd/ChangeLog: * warning.m4: Stop appending "-Wstack-usage=262144" option when compiled with Clang. * configure: Regenerate. binutils/ChangeLog: * configure: Regenerate. gas/ChangeLog: * configure: Regenerate. gold/ChangeLog: * configure: Regenerate. gprof/ChangeLog: * configure: Regenerate. ld/ChangeLog: * configure: Regenerate. opcodes/ChangeLog: * configure: Regenerate.
2022-09-14ubsan: arm-dis.c index out of boundsAlan Modra1-1/+1
We are way off in the weeds with this one, and will be printing <UNPREDICTABLE> for S > 10. * arm-dis.c (print_insn_cde): Wrap 'T' value.
2022-09-12ppc: Document the -mfuture and -Mfuture options and make them usablePeter Bergner2-1/+3
The -mfuture and -Mfuture options which are used for adding potential new ISA instructions were not documented. They also lacked a bitmask so new instructions could not be enabled by those options. Fixed. binutils/ * doc/binutils.texi: Document -Mfuture. gas/ * config/tc-ppc.c: Document -mfuture * doc/c-ppc.texi: Likewise. include/ * opcode/ppc.h (PPC_OPCODE_FUTURE): Define. opcodes/ * ppc-dis.c (ppc_opts) <future>: Use it. * ppc-opc.c (FUTURE): Define.
2022-09-12x86: avoid i386_dis_printf()'s staging area for a fair part of outputJan Beulich1-20/+24
While PR binutils/29483 has now been addressed differently, this originally proposed change still has its merits: Avoiding vsnprintf() for typically far more than half of the overall output results in a 2-3% performance gain in my testing (with debug builds of objdump, libbfd, and libopcodes). With that part of output no longer using staging_area[], the array also doesn't need to be quite as large anymore (the largest presently used size is 27, from "64-bit address is disabled"). While limiting the scope of "res" it became apparent that - no caller cares about the function's return value, - the comment about the return value was wrong, - a particular positive return value would have been meaningless to the caller. Therefore convert the function to return "void" at the same time.
2022-09-06opcodes: Add non-enum disassembler optionsTsukasa OI3-0/+6
This is paired with "gdb: Add non-enum disassembler options". There is a portable mechanism for disassembler options and used on some architectures: - ARC - Arm - MIPS - PowerPC - RISC-V - S/390 However, it only supports following forms: - [NAME] - [NAME]=[ENUM_VALUE] Valid values for [ENUM_VALUE] must be predefined in disasm_option_arg_t.values. For instance, for -M cpu=[CPU] in ARC architecture, opcodes/arc-dis.c builds valid CPU model list from include/elf/arc-cpu.def. In this commit, it adds following format: - [NAME]=[ARBITRARY_VALUE] (cannot contain "," though) This is identified by NULL value of disasm_option_arg_t.values (normally, this is a non-NULL pointer to a NULL-terminated list). include/ChangeLog: * dis-asm.h (disasm_option_arg_t): Update comment of values to allow non-enum disassembler options. opcodes/ChangeLog: * riscv-dis.c (print_riscv_disassembler_options): Support non-enum disassembler options on printing disassembler help. * arc-dis.c (print_arc_disassembler_options): Likewise. * mips-dis.c (print_mips_disassembler_options): Likewise.
2022-09-02RISC-V: Print highest address (-1) on the disassemblerTsukasa OI1-6/+14
This patch makes possible to print the highest address (-1) and the addresses related to gp which value is -1. This is particularly useful if the highest address space is used for I/O registers and corresponding symbols are defined. Besides, despite that it is very rare to have GP the highest address, it would be nice because we enabled highest address printing on regular cases. gas/ChangeLog: * testsuite/gas/riscv/dis-addr-topaddr.s: New test for the top address (-1) printing. * testsuite/gas/riscv/dis-addr-topaddr-32.d: Likewise. * testsuite/gas/riscv/dis-addr-topaddr-64.d: Likewise. * testsuite/gas/riscv/dis-addr-topaddr-gp.s: New test for GP-relative addressing when GP is the highest address (-1). * testsuite/gas/riscv/dis-addr-topaddr-gp-32.d: Likewise. * testsuite/gas/riscv/dis-addr-topaddr-gp-64.d: Likewise. opcodes/ChangeLog: * riscv-dis.c (struct riscv_private_data): Add `to_print_addr' to enable printing the highest address. (maybe_print_address): Utilize `to_print_addr'. (riscv_disassemble_insn): Likewise.
2022-09-02RISC-V: PR29342, Fix RV32 disassembler address computationTsukasa OI1-1/+7
If either the base register is `zero', `tp' or `gp' and XLEN is 32, an incorrectly sign-extended address is produced when printing. This commit fixes this by fitting an address into a 32-bit value on RV32. Besides, H. Peter Anvin discovered that we have wrong address computation for JALR instruction (the initial bug is back in 2018). This commit also fixes that based on the idea of Palmer Dabbelt. gas/ pr29342 * testsuite/gas/riscv/lla32.d: Reflect RV32 address computation fix. * testsuite/gas/riscv/dis-addr-overflow.s: New testcase. * testsuite/gas/riscv/dis-addr-overflow-32.d: Likewise. * testsuite/gas/riscv/dis-addr-overflow-64.d: Likewise. opcodes/ pr29342 * riscv-dis.c (maybe_print_address): Fit address into 32-bit on RV32. (print_insn_args): Fix JALR address by adding EXTRACT_ITYPE_IMM.
2022-08-30RISC-V: Add 'Zmmul' extension in assembler.Tsukasa OI1-13/+13
Three-part patch set from Tsukasa OI to support zmmul in assembler. The 'Zmmul' is a RISC-V extension consisting of only multiply instructions (a subset of 'M' which has multiply and divide instructions). bfd/ * elfxx-riscv.c (riscv_implicit_subsets): Add 'Zmmul' implied by 'M'. (riscv_supported_std_z_ext): Add 'Zmmul' extension. (riscv_multi_subset_supports): Add handling for new instruction class. gas/ * testsuite/gas/riscv/attribute-09.d: Updated implicit 'Zmmul' by 'M'. * testsuite/gas/riscv/option-arch-02.d: Likewise. * testsuite/gas/riscv/m-ext.s: New test. * testsuite/gas/riscv/m-ext-32.d: New test (RV32). * testsuite/gas/riscv/m-ext-64.d: New test (RV64). * testsuite/gas/riscv/zmmul-32.d: New expected output. * testsuite/gas/riscv/zmmul-64.d: Likewise. * testsuite/gas/riscv/m-ext-fail-xlen-32.d: New test (failure by using RV64-only instructions in RV32). * testsuite/gas/riscv/m-ext-fail-xlen-32.l: Likewise. * testsuite/gas/riscv/m-ext-fail-zmmul-32.d: New failure test (RV32 + Zmmul but with no M). * testsuite/gas/riscv/m-ext-fail-zmmul-32.l: Likewise. * testsuite/gas/riscv/m-ext-fail-zmmul-64.d: New failure test (RV64 + Zmmul but with no M). * testsuite/gas/riscv/m-ext-fail-zmmul-64.l: Likewise. * testsuite/gas/riscv/m-ext-fail-noarch-64.d: New failure test (no Zmmul or M). * testsuite/gas/riscv/m-ext-fail-noarch-64.l: Likewise. include/ * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_ZMMUL. ld/ * testsuite/ld-riscv-elf/attr-merge-arch-01.d: We don't care zmmul in these testcases, so just replaced m by a. * testsuite/ld-riscv-elf/attr-merge-arch-01a.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-01b.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-02a.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-arch-03a.s: Likewise. * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Likewise. * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p0.s: Renamed. * testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i2p1_a2p1.s: Renamed. opcodes/ * riscv-opc.c (riscv_opcodes): Updated multiply instructions to zmmul.
2022-08-16i386: Add MAX_OPERAND_BUFFER_SIZEH.J. Lu1-3/+6
When displaying operands, invalid opcodes may overflow operand buffer due to additional styling characters. Each style is encoded with 3 bytes. Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles in an operand. gas/ PR binutils/29483 * testsuite/gas/i386/i386.exp: Run pr29483. * testsuite/gas/i386/pr29483.d: New file. * testsuite/gas/i386/pr29483.s: Likewise. opcodes/ PR binutils/29483 * i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New. (obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE. (staging_area): Likewise. (op_out): Likewise.
2022-08-16x86: shorten certain template namesJan Beulich1-26/+32
Now that we can purge templates, let's use this to improve readability a little by shortening a few of their names, making functionally similar ones also have identical names in their multiple incarnations.
2022-08-16x86: template-ize certain vector conversion insnsJan Beulich3-181/+167
Many of the vector conversion insns come with X/Y/Z suffixed forms, for disambiguation purposes in AT&T syntax. All of these gorups follow certain patterns. Introduce "xy" and "xyz" templates to reduce redundancy. To facilitate using a uniform name for both AVX and AVX512, further introduce a means to purge a previously defined template: A standalone <name> will be recognized to have this effect. Note that in the course of the conversion VFPCLASSPH is properly split to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D} and yielding the intended "ambiguous operand size" diagnostic in Intel mode.
2022-08-16x86: template-ize vector packed byte/word integer insnsJan Beulich2-763/+692
Many of the vector integer insns come in byte/word element pairs. Most of these pairs follow certain encoding patterns. Introduce a "bw" template to reduce redundancy. Note that in the course of the conversion - the AVX VPEXTRW template which is not being touched needs to remain ahead of the new "combined" ones, as (a) this should be tried first when matching insns against templates and (b) its Load attributes requires it to be first, - this add a benign/meaningless IgnoreSize attribute to the memory form of PEXTRB; it didn't seem worth avoiding this.
2022-08-16x86: re-order AVX512 S/G templatesJan Beulich2-185/+182
The AVX2 gather ones are nicely grouped - do the same for the various AVX512 scatter/gather ones. On the moved lines also convert EVex=<n> to EVex<N>.
2022-08-16x86: template-ize vector packed dword/qword integer insnsJan Beulich2-615/+518
Many of the vector integer insns come in dword/qword element pairs. Most of these pairs follow certain encoding patterns. Introduce a "dq" template to reduce redundancy. Note that in the course of the conversion - a few otherwise untouched templates are moved, so they end up next to their siblings), - drop an unhelpful Cpu64 from the GPR form of VPBROADCASTQ, matching what we already have for KMOVQ - the diagnostic is better this way for insns with multiple forms (i.e. the same Cpu64 attributes on {,V}MOVQ, {,V}PEXTRQ, and {,V}PINSRQ are useful to keep), - this adds benign/meaningless IgnoreSize attributes to the GPR forms of KMOVD and VPBROADCASTD; it didn't seem worth avoiding this.
2022-08-16x86: template-ize packed/scalar vector floating point insnsJan Beulich3-3577/+3345
The vast majority of vector FP insns comes in single/double pairs. Many pairs follow certain encoding patterns. Introduce an "sd" template to reduce redundancy. Similarly, to further cover similarities between AVX512F and AVX512-FP16, introduce an "sdh" template. For element-size Disp8 shift generalize i386-gen's broadcast size determination, allowing Disp8MemShift to be specified without an operand in the affected templated templates. While doing the adjustment also eliminate an unhelpful (lost information) diagnostic combined with a use after free in what is now get_element_size(). Note that in the course of the conversion - the AVX512F form of VMOVUPD has a stray (leftover) Load attribute dropped, - VMOVSH has a benign IgnoreSize added (the attribute is still strictly necessary for VMOVSD, and necessary for VMOVSS as long as we permit strange combinations like "-march=i286+avx"), - VFPCLASSPH is properly split to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D}.
2022-08-16revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"Jan Beulich4-32/+56
This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which broke i386-gen's emitting of diagnostics. As a replacement to address the original issue of newer gcc no longer splicing lines when dropping the line continuation backslashes, switch to using + as the line continuation character, doing the line splicing in i386-gen.
2022-08-11ppc/svp64: support svindex instructionDmitry Selyutin1-0/+15
https://libre-soc.org/openpower/sv/ https://libre-soc.org/openpower/sv/remap/#svindex https://libre-soc.org/openpower/isa/simplev/
2022-08-11ppc/svp64: support svremap instructionDmitry Selyutin1-0/+20
https://libre-soc.org/openpower/sv/ https://libre-soc.org/openpower/sv/remap/#svremap https://libre-soc.org/openpower/isa/simplev/
2022-08-11ppc/svp64: support svshape instructionDmitry Selyutin1-0/+23
https://libre-soc.org/openpower/sv/ https://libre-soc.org/openpower/sv/remap/#svshape https://libre-soc.org/openpower/isa/simplev/
2022-08-11ppc/svp64: support svstep instructionsDmitry Selyutin1-0/+3
https://libre-soc.org/openpower/sv/ https://libre-soc.org/openpower/sv/svstep/ https://libre-soc.org/openpower/isa/simplev/
2022-08-11ppc/svp64: support setvl instructionsDmitry Selyutin1-0/+22
https://libre-soc.org/openpower/sv/ https://libre-soc.org/openpower/sv/setvl/ https://libre-soc.org/openpower/isa/simplev/
2022-08-11ppc/svp64: introduce non-zero operand flagDmitry Selyutin1-0/+3
svstep and svshape instructions subtract 1 before encoding some of the operands. Obviously zero is not supported for these operands. Whilst PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be incremented, there is no flag which marks the fact that zero values are not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this purpose.
2022-08-11ppc/svp64: support LibreSOC architectureDmitry Selyutin2-8/+14
This patch adds support for LibreSOC machine and SVP64 extension flag for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit Prefixed instruction format implementing SV. Funded by NLnet through EU Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly submitted via the OpenPOWER Foundation ISA Working Group via the newly-created External RFC Process. For more details, visit https://libre-soc.org.
2022-08-09x86-64: adjust MOVQ to/from SReg attributesJan Beulich2-3/+3
It is unclear to me why the corresponding MOV (no Q suffix) can be issued without REX.W, but MOVQ has to have that prefix (bit). Add NoRex64 and in exchange drop Size64.
2022-08-09x86: adjust MOVSD attributesJan Beulich2-3/+3
The non-SSE2AVX form of the SIMD variant of the instruction needlessly has the (still multi-purpose) IgnoreSize attribute. All other similar SSE2 insns use NoRex64 instead. Make this consistent, noting that the SSE2AVX form can't have the same change made - there the memory operand doesn't at the same time permit RegXMM (which logic uses when deciding whether a Q suffix is okay outside of 64-bit mode).
2022-08-09x86: fold AVX VGATHERDPD / VPGATHERDQJan Beulich2-44/+8
While the other three variants each differ in attributes and hence can't be folded, these two pairs actually can be (and were previously overlooked). This effectively matches their AVX512VL counterparts, which are also expressed as a single template.
2022-08-09x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insnsJan Beulich2-54/+54
While the x/y/z suffix isn't necessary to use in this case, it is still odd that these forms don't support broadcast (unlike their AVX512F / AVX512DQ counterparts). The lack thereof can e.g. make macro-ized programming more difficult.
2022-08-09x86/Intel: split certain AVX512-FP16 VCVT*2PH templatesJan Beulich2-12/+108
One more place where pre-existing templates should have been taken as a basis: In Intel syntax we want to consistently issue an "ambiguous operand size" error when a size-less memory operand is specified for an insn where register use alone isn't sufficient for disambiguation.
2022-08-04Don't use BFD_VMA_FMT in binutilsAlan Modra1-3/+3
BFD_VMA_FMT can't be used in format strings that need to be translated, because the translation won't work when the type of bfd_vma differs from the machine used to compile .pot files. We've known about this for a long time, but patches slip through review. So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64, PRIu64, PRIx64 or PRIo64 and SCN variants for scanf. The patch is mostly mechanical, the only thing requiring any thought is casts needed to preserve PRId64 output from bfd_vma values, or to preserve one of the unsigned output formats from bfd_signed_vma values.
2022-08-03x86: properly mark i386-only insnsJan Beulich2-30/+30
Just like all Size64 insns are marked Cpu64, all Size32 insns ought to be marked Cpu386.
2022-08-03x86: also use D for MOVBEJan Beulich3-19/+3
First of all rename the meanwhile misleading Opcode_SIMD_FloatD, as it has also been used for KMOV* and BNDMOV. Then simplify the condition selecting which form if "reversing" to use - except for the MOV to/from control/debug/test registers all extended opcode space insns use bit 0 (rather than bit 1) to indicate the direction (from/to memory) of an operation. With that, D can simply be set on the first of the two templates, while the other can be dropped.
2022-08-02x86: XOP shift insns don't really allow B suffixJan Beulich2-20/+20
By mistake it was permitted to be used from the very introduction of XOP support.
2022-08-01x86: SKINIT with operand needs IgnoreSizeJan Beulich2-2/+2
Without it in 16-bit mode a pointless operand size prefix would be emitted.
2022-08-01opcodes: LoongArch: add "ret" instruction to reduce typingWANG Xuerui1-0/+1
This syntactic sugar is present in both classical and emerging architectures, like Alpha, SPARC and RISC-V, and assembler macros doing the same thing can already be found in the wild e.g. [1], proving the feature's popularity. It's better to provide support directly in the assembler so downstream users wouldn't have to re-invent this over and over again. [1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/loongarch/sysdep.h;h=c586df819cd90;hb=HEAD#l28
2022-08-01opcodes: LoongArch: make all non-native jumps desugar to canonical ↵WANG Xuerui1-19/+12
b{lt/ge}[u] forms Also re-order the jump/branch opcodes while at it, so that insns are sorted in ascending order according to opcodes, and the label form preceding the real definition.
2022-08-01Get rid of fprintf_vma and sprintf_vmaAlan Modra5-50/+17
These two macros print either a 16 digit hex number or an 8 digit hex number. Unfortunately they depend on both target and host, which means that the output for 32-bit targets may be either 8 or 16 hex digits. Replace them in most cases with code that prints a bfd_vma using PRIx64. In some cases, deliberately lose the leading zeros. This change some output, notably in base/offset fields of m68k disassembly which I think looks better that way, and in error messages. I've kept leading zeros in symbol dumps (objdump -t) and in PE header dumps. bfd/ * bfd-in.h (fprintf_vma, sprintf_vma, printf_vma): Delete. * bfd-in2.h: Regenerate. * bfd.c (bfd_sprintf_vma): Don't use sprintf_vma. (bfd_fprintf_vma): Don't use fprintf_vma. * coff-rs6000.c (xcoff_reloc_type_tls): Don't use sprintf_vma. Instead use PRIx64 to print bfd_vma values. (xcoff_ppc_relocate_section): Likewise. * cofflink.c (_bfd_coff_write_global_sym): Likewise. * mmo.c (mmo_write_symbols_and_terminator): Likewise. * srec.c (srec_write_symbols): Likewise. * elf32-xtensa.c (print_r_reloc): Similarly for fprintf_vma. * pei-x86_64.c (pex64_dump_xdata): Likewise. (pex64_bfd_print_pdata_section): Likewise. * som.c (som_print_symbol): Likewise. * ecoff.c (_bfd_ecoff_print_symbol): Use bfd_fprintf_vma. opcodes/ * dis-buf.c (perror_memory, generic_print_address): Don't use sprintf_vma. Instead use PRIx64 to print bfd_vma values. * i386-dis.c (print_operand_value, print_displacement): Likewise. * m68k-dis.c (print_base, print_indexed): Likewise. * ns32k-dis.c (print_insn_arg): Likewise. * ia64-gen.c (_opcode_int64_low, _opcode_int64_high): Delete. (opcode_fprintf_vma): Delete. (print_main_table): Use PRIx64 to print opcode. binutils/ * od-macho.c: Replace all uses of printf_vma with bfd_printf_vma. * objcopy.c (copy_object): Don't use sprintf_vma. Instead use PRIx64 to print bfd_vma values. (copy_main): Likewise. * readelf.c (CHECK_ENTSIZE_VALUES): Likewise. (dynamic_section_mips_val): Likewise. (print_vma): Don't use printf_vma. Instead use PRIx64 to print bfd_vma values. (dump_ia64_vms_dynamic_fixups): Likewise. (process_version_sections): Likewise. * rddbg.c (stab_context): Likewise. gas/ * config/tc-i386.c (offset_in_range): Don't use sprintf_vma. Instead use PRIx64 to print bfd_vma values. (md_assemble): Likewise. * config/tc-mips.c (load_register, macro): Likewise. * messages.c (as_internal_value_out_of_range): Likewise. * read.c (emit_expr_with_reloc): Likewise. * config/tc-ia64.c (note_register_values): Don't use fprintf_vma. Instead use PRIx64 to print bfd_vma values. (print_dependency): Likewise. * listing.c (list_symbol_table): Use bfd_sprintf_vma. * symbols.c (print_symbol_value_1): Use %p to print pointers. (print_binary): Likewise. (print_expr_1): Use PRIx64 to print bfd_vma values. * write.c (print_fixup): Use %p to print pointers. Don't use fprintf_vma. * testsuite/gas/all/overflow.l: Update expected output. * testsuite/gas/m68k/mcf-mov3q.d: Likewise. * testsuite/gas/m68k/operands.d: Likewise. * testsuite/gas/s12z/truncated.d: Likewise. ld/ * deffilep.y (def_file_print): Don't use fprintf_vma. Instead use PRIx64 to print bfd_vma values. * emultempl/armelf.em (gld${EMULATION_NAME}_finish): Don't use sprintf_vma. Instead use PRIx64 to print bfd_vma values. * emultempl/pe.em (gld${EMULATION_NAME}_finish): Likewise. * ldlang.c (lang_map): Use %V to print region origin. (lang_one_common): Don't use sprintf_vma. * ldmisc.c (vfinfo): Don't use fprintf_vma or sprintf_vma. * pe-dll.c (pe_dll_generate_def_file): Likewise. gdb/ * remote.c (remote_target::trace_set_readonly_regions): Replace uses of sprintf_vma with bfd_sprintf_vma.
2022-07-29libopcodes/aarch64: add support for disassembler stylingAndrew Burgess3-177/+516
This commit enables disassembler styling for AArch64. After this commit it is possible to have objdump style AArch64 disassembler output (using --disassembler-color option). Once the required GDB patches are merged, GDB will also style the disassembler output. The changes to support styling are mostly split between two files opcodes/aarch64-dis.c and opcodes/aarch64-opc.c. The entry point for the AArch64 disassembler can be found in aarch64-dis.c, this file handles printing the instruction mnemonics, and assembler directives (e.g. '.byte', '.word', etc). Some operands, mostly relating to assembler directives are also printed from this file. This commit changes all of this to pass through suitable styling information. However, for most "normal" instructions, the instruction operands are printed using a two step process. From aarch64-dis.c, in the print_operands function, the function aarch64_print_operand is called, this function is in aarch64-opc.c, and converts an instruction operand into a string. Then, back in print_operands (aarch64-dis.c), the operand string is printed. Unfortunately, the string returned by aarch64_print_operand can be quite complex, it will include syntax elements, like '[' and ']', in addition to register names and immediate values. In some cases, a single operand will expand into what will appear (to the user) as multiple operands separated with a ','. This makes the task of styling more complex, all these different components need to by styled differently, so we need to get the styling information out of aarch64_print_operand in some way. The solution that I propose here is similar to the solution that I used for the i386 disassembler. Currently, aarch64_print_operand uses snprintf to write the operand text into a buffer provided by the caller. What I propose is that we pass an extra argument to the aarch64_print_operand function, this argument will be a structure, the structure contains a callback function and some state. When aarch64_print_operand needs to format part of its output this can be done by using the callback function within the new structure, this callback returns a string with special embedded markers that indicate which mode should be used for each piece of text. Back in aarch64-dis.c we can spot these special style markers and use this to split the disassembler output up and apply the correct style to each piece. To make aarch64-opc.c clearer a series of new static functions have been added, e.g. 'style_reg', 'style_imm', etc. Each of these functions formats a piece of text in a different style, 'register' and 'immediate' in this case. Here's an example taken from aarch64-opc.c of the new functions in use: snprintf (buf, size, "[%s, %s]!", style_reg (styler, base), style_imm (styler, "#%d", opnd->addr.offset.imm)); The aarch64_print_operand function is also called from the assembler to aid in printing diagnostic messages. Right now I have no plans to add styling to the assembler output, and so, the callback function used in the assembler ignores the styling information and just returns an plain string. I've used the source files in gas/testsuite/gas/aarch64/ for testing, and have manually gone through and checked that the styling looks reasonable, however, I'm not an AArch64 expert, so it is possible that the odd piece is styled incorrectly. Please point out any mistakes I've made. With objdump disassembler color turned off, there should be no change in the output after this commit.
generated by cgit v1.1 at 2025-01-11 12:02:20 +0000