FEAT_PCDPHINT - Producer-consumer data placement hints - is an optional
ISA extension that provides hint instructions to indicate:
- a store in the current execution thread is generating data at a specific
location, which a thread of execution on one or more other observers is
waiting on.
- the thread of execution on the current PE will read a location that may not
yet have been written with the value to be consumed.
This extension introduces:
- STSHH, a hint instruction, with operands (policies) keep and strm
- PRFM *IR*, a new prefetch memory operand.
Swap AM_PO_SUBDIRS and ZW_GNU_GETTEXT_SISTER_DIR lines in
*/configure.ac. ZW_GNU_GETTEXT_SISTER_DIR indirectly invokes
AC_REQUIRE(AM_PO_SUBDIRS) so results in AM_PO_SUBDIRS being emitted
before ZW_GNU_GETTEXT_SISTER_DIR if it hasn't already been invoked.
This also fix the imply result for .option rvc.
Imply zcf when c and f and rv32
Imply zcd when c and d
Imply zca when c
Changed INSN_CLASS_C to INSN_CLASS_ZCA
Changed INSN_CLASS_F_AND_C to INSN_CLASS_ZCF
Changed INSN_CLASS_D_AND_C to INSN_CLASS_ZCD
Changed INSN_CLASS_ZIHINTNTL_AND_C to INSN_CLASS_ZIHINTNTL_AND_ZCA
This patch add support for FEAT_PoPS feature which can be enabled
through +pops command line flag.
This patch also adds support for following DC instructions and the
spec can be found here [1].
1. "dc cigdvaps" enabled on passing +memtag+pops command line flags.
2. "dc civaps" enabled on passing +pops command line flag.
[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Instructions?lang=en
There are some OpenRISC CPUs that have their binaries stored in
little-endian format. Using objdump to disassemble these is
problematic, as some instructions fail to disassemble, for example:
objdump -D -b binary -EB -m or1k test_be.bin
0: 18 60 07 27 l.movhi r3,0x727
4: a8 63 0e 00 l.ori r3,r3,0xe00
8: 9c 63 ff ff l.addi r3,r3,-1
c: bc 43 00 00 l.sfgtui r3,0
10: 13 ff ff fe l.bf 0x8
14: 44 00 48 00 l.jr r9
objdump -D -b binary -EL -m or1k test_le.bin
0: 27 07 60 18 *unknown*
4: 00 0e 63 a8 l.ori r3,r3,0xe00
8: ff ff 63 9c *unknown*
c: 00 00 43 bc l.sfgtui r3,0
10: fe ff ff 13 *unknown*
14: 00 48 00 44 l.jr r9
It was found that the hash function was using the still little-endian
buffer to extract the opcode used for the hash lookup. This didn't work
as it was pulling the wrong hashcode causing instruction lookup to fail.
Fix the hash function by using the normalized/byte-swapped value instead
of the buffer.
Signed-off-by: Stafford Horne <shorne@gmail.com>
This patch adds support for following system registers and the spec
can be found here[1].
1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE
and Armv9.5-A architecture and these are enabled by passing
-march=armv9.5-a+profile.
2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture
and these are enabled by passing -march=armv9.5-a.
3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing
-march=armv8.8-a.
[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Registers?lang=en
FEAT_SVE_F16F32MM introduces the SVE half-precision floating-point
matrix multiply-accumulate to single-precision instruction.
FEAT_F8F32MM introduces the Advanced SIMD 8-bit floating-point matrix
multiply-accumulate to single-precision instruction.
FEAT_F8F16MM introduces the Advanced SIMD 8-bit floating-point matrix
multiply-accumulate to half-precision instruction.
FEAT_CMPBR - Compare and branch instructions. This patch adds these
instructions:
- CB<CC> (register)
- CB<CC> (immediate)
- CBH<CC>
- CBB<CC>
where CC is one of the following:
- EQ
- NE
- GT
- GE
- LT
- LE
- HI
- HS
- LO
- LS
FEAT_OCCMO support was introduced, but the feature flags were missing.
This patch adds these flags, as well as splitting up the tests to test
occmo vs occmo+memtag operands.
FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in
Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also
introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE
and BFMUL.
These are needed when running GCC tests for newlib toolchains built with
multicore support. Without these SPRs we get the following warnings
when running tests.
spawn or1k-elf-run ./20000112-1.exe^M
WARNING: l.mfspr with invalid SPR address 0x80^M
WARNING: l.mfspr with invalid SPR address 0x81^M
WARNING: l.mfspr with invalid SPR address 0x81^M
WARNING: l.mfspr with invalid SPR address 0x81^M
Support is added by defining the SPRs in the cgen machine definition and
regenerating the machine code. In or1k/or1k.c we initialize NUMCORES to
1 and COREID to 0 as the sim has only one CPU. In or1k/traps.c we allow
returning the NUMCORES and COREID spr values in the mfspr function.
Signed-off-by: Stafford Horne <shorne@gmail.com>
They can be used like their %al/%cl counterparts everywhere else;
there's no apparent reason why they shouldn't be usable as accumulator /
shift count respectively. Enforcing such a restriction only makes
writing heavily macro-ized code more cumbersome.
In a number of places we assume that immediates come first in the set of
operands. It is mere luck that so far OUT, having operands the other way
around, wasn't negatively impacted by this.
Leverage this to have a few loops start from the first non-immediate
operand (or in one case to stop there). Note, however, that
process_immext() inserts an immediate last, so especially all output_*()
functions cannot be changed in the same way.
While documentation of these continues to be lacking sufficient detail,
it is becoming increasingly clear that in 66f1eba0b7 ("x86: correct
UDn") I went too far with requiring operands, to populate a ModR/M byte.
AMD hardware appears to always behave as indicated as "may" in PM 3.36,
which for all practical purposes means there's no ModR/M byte. The SDM
(rev 087) indicates that such behavior can occur on older hardware for
UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while
newly adding such a form also for UD0. Because of the ambiguity, there's
no good/easy way of handling both possibilities in the disassembler,
which hence remains unaltered.
Further, from all information I'm able to gather, the 0F opcode space
was only introduced with the i286; bump the minimal hardware requirement
for all UD<n> accordingly.
FEAT_FPRCVT introduces new versions of previous instructions.
The instructions are used to convert between floating points and
Integers. These new versions take as operands SIMD&FP registers
for both the source and destination register. FEAT_FPRCVT also
enables the use of some existing AdvSIMD instructions in
streaming mode. However, no changes are needed in gas to support this.
This patch adds support for new system registers introduced in the
2024 MPAM extension (Memory Partitioning and Monitoring):
Available in Armv9.3-A:
MPAMBW0_EL1,
MPAMBW1_EL1,
MPAMBW1_EL12,
MPAMBW2_EL2,
MPAMBW3_EL3,
MPAMBWCAP_EL2,
MPAMBWIDR_EL1
Available in Armv9.3-A with SME:
MPAMBWSM_EL1
The details can be found in [1].
[1]: https://developer.arm.com/documentation/ddi0601/latest
Diagnosing operand size vs operand type mismatches doesn't work very
well when GPRs and FPRs are in the same register class, distinguished
just by size. Introduce a separate RegFP class.
The comment explaining the placement of the cfinv entry before the
generic msr entry in the opcode table was incorrect. The issue is
unrelated to the all ones bitmask for cfinv, and is actually due the
large number of architectural aliases of the msr instruction.
FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
a method for defining a set of windows in the memory map for which
Granule Protection Checks are skipped, and instead applies a set of
default settings associated with the window.
This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
access this sysreg since this feature is optional from armv9.5-a.
FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
system instructions that provides software with a mechanism to publish
writes to the Outer cache level.
Using explicit pseudo aliases is clearer and more consistent with other
instruction aliases.
This does not change behaviour. For the non-alias instructions
(everything except mov) we already picked the first matching entry for
disassembly by default. For mov we picked the last matching aliased
entry, which remained the original alias since do_misc_decoding doesn't
recognise OP_MOV_PN_PN.
This was an early name for the clrbhb hint instruction. Some software
was written with the old name before it was renamed, so we support it
for assembly but should never use it in disassembly.
This patch has no functional change, because we already pick (by
default) the last matching alias in the opcode table, and clrbhb is
listed later than clearbhb.
Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept
implicit XZR offsets. Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands
to support instructions where an XZR offset is allowed but must be
specified explicitly. This allows the removal of the duplicate opcode
table entries using AARCH64_OPND_SVE_ADDR_R.
They are instruction alias, but not mark correctly, and seems like we
don't have a good way to verify that since the disassembler doesn't
disassemble instruction into alias.
[1] https://github.com/riscv-non-isa/riscv-asm-manual/pull/124
We have a discrepancy with 64-bit BFD handling across our component
subdirectories leading to link failures such as:
ld: ../opcodes/.libs/libopcodes.a(disassemble.o): in function `disassembler': disassemble.c:(.text+0x65): undefined reference to `print_insn_alpha'
ld: disassemble.c:(.text+0x105): undefined reference to `print_insn_ia64'
ld: disassemble.c:(.text+0x11d): undefined reference to `print_insn_loongarch'
ld: disassemble.c:(.text+0x1a1): undefined reference to `print_insn_big_mips'
[...]
with some configurations having a 32-bit host and 64-bit BFD, such as:
`--host=i386-linux-gnu --target=riscv64-linux-gnu --enable-targets=all'.
This is ultimately due to how 64-bit BFD is enabled for bfd/ itself and
other subdirectorses and has been a regression from commit 1d5269c994
("unify 64-bit bfd checks").
For bfd/ the BFD_64_BIT autoconf macro from config/bfd64.m4 is used
combined with this logic in bfd/configure.ac:
case ${host64}-${target64}-${want64} in
*true*)
wordsize=64
bfd64_libs='$(BFD64_LIBS)'
all_backends='$(BFD64_BACKENDS) $(BFD32_BACKENDS)'
[...]
;;
false-false-false)
wordsize=32
all_backends='$(BFD32_BACKENDS)'
;;
esac
where the value of ${wordsize} switches between 32-bit and 64-bit BFD
via these pieces:
#define BFD_ARCH_SIZE @wordsize@
and:
#if BFD_ARCH_SIZE >= 64
#define BFD64
#endif
in bfd/bfd-in.h, which ultimately becomes a part of "bfd.h".
Then ${host64} is determined in bfd/configure.ac from the host's word
size, via the host's pointer size:
if test "x${ac_cv_sizeof_void_p}" = "x8"; then
host64=true
fi
And ${target64} is determined in bfd/configure.ac from the target's word
size:
if test ${target_size} = 64; then
target64=true
fi
Where multiple targets have been requested with `--enable-targets=all'
the presence of any 64-bit target will set "true" here.
Finally ${want64} is set according to `--enable-64-bit-bfd' user option
with an arrangement involving BFD_64_BIT:
BFD_64_BIT
if test $enable_64_bit_bfd = yes ; then
want64=true
else
want64=false
fi
which also, redundantly, checks and sets its result upon the host's word
size. Lastly ${want64} is also selectively set by target fragments in
bfd/config.bfd, which mostly if not completely overlaps with ${target64}
setting as described above.
Conversely other subdirectories only rely on BFD_64_BIT, so they fail to
notice that BFD is 64-bit and do not enable their 64-bit handling where
the host requested is 32-bit and 64-bit BFD has been enabled other than
with `--enable-64-bit-bfd'. One consequence is opcodes/disassemble.c
enables calls to its numerous own 64-bit backends by checking the BFD64
macro from "bfd.h", however does not actually enable said backends in
its Makefile. Hence the link errors quoted above.
Address the problem then by moving the `--enable-64-bit-bfd' option back
to bfd/configure.ac and remove the call to BFD_64_BIT from there and
then rewrite the macro in terms of checking for the presence of BFD64
macro in "bfd.h", which is the canonical way of determining whether BFD
is 64-bit or not.
Rather than running `grep' directly on ../bfd/bfd-in3.h as the opcodes/
fragment used to before the problematic commit:
if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null; then
run the preprocessor on "bfd.h", which allows to invoke the macro from
configure.ac files placed in subdirectories located at deeper levels, by
relying on the preprocessor's search path.
This requires however that the invokers rely on `all-bfd' rather than
`configure-bfd' for their `configure' invocation stage, because "bfd.h"
is made by `make all' rather than `configure' in bfd/.
Do not cache the result of this check however, as reconfiguring a tree
such as to flip `--enable-64-bit-bfd' on or to change a secondary target
may affect BFD64 and we have no access to information about secondary
targets in BFD_64_BIT.
Also remove the ENABLE_BFD_64_BIT automake conditional, as it's not used
anywhere.
Last but not least remove the hack from gdb/configure.ac to fail builds
for `mips*-*-*' hosts where `--enable-targets=all' has been requested,
but `--enable-64-bit-bfd' has not as it's no longer needed. Such builds
complete successfully now, having enabled 64-bit BFD implicitly.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Alan Modra <amodra@gmail.com>
Approved-By: Luis Machado <luis.machado@arm.com>
... to be all in one group. This helps code generation for code like
|| is_cpu (&i.tm, CpuPadLock)
|| is_cpu (&i.tm, CpuPadLockRNG2)
|| is_cpu (&i.tm, CpuPadLockPHE2)
|| is_cpu (&i.tm, CpuPadLockXMODX)
that we have (effectively) twice.
These LA32R instructions are in fact special cases of the LA32S/LA64
rdtime{l,h}.w (with only one output operand instead of two, the other
one being forced to $zero), but are named differently in the LA32R
ISA manual nevertheless.
As the LA32R names are more memorable to a degree (especially for those
having difficulties remembering which operand corresponds to the node
ID), support them by making them aliases of the corresponding LA32S/LA64
instruction respectively, and make them render as such in disassembly.
Signed-off-by: WANG Xuerui <git@xen0n.name>
So far IBM z17 was identified as arch15. Add the real name, as it has
been announced. [1]
[1]: IBM z17 announcement letter, AD25-0015,
https://www.ibm.com/docs/en/announcements/z17-makes-more-possible
gas/
* config/tc-s390.c (s390_parse_cpu): Add z17 as alternate CPU
name for arch15.
* doc/c-s390.texi: Likewise.
* doc/as.texi: Likewise.
opcodes/
* s390-mkopc.c (main): Add z17 as alternate CPU name for arch15.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
The privileged spec 1.9.1 support was removed since binutils 2.43. The
linker only recognizes it and then reports a warning that it may
conflict with other spec versions.
While the support is removed, binutils should still recognize it, but it
shouldn't be exposed to the user in `disassember-options` help.
Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit
rounding is not that useful because we currently have rounding feature
directly on E-core now and no need to use 256-bit rounding as somehow
a workaround. This patch will remove all the support and backport to
Binutils 2.44.
gas/ChangeLog:
* NEWS: Mention support removal.
* config/tc-i386.c (build_evex_prefix): Remove U bit encode.
(check_VecOperands): Remove ymm check for rounding.
(s_insn): Revise .insn comment.
* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm
rounding related test.
* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/evex.d: Ditto.
* testsuite/gas/i386/evex.s: Ditto.
* testsuite/gas/i386/i386.exp: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-evex.d: Ditto.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.l: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.s: Removed.
* testsuite/gas/i386/avx10_2-rounding.d: Removed.
* testsuite/gas/i386/avx10_2-rounding.s: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed.
opcodes/ChangeLog:
* i386-dis.c (struct instr_info): Remove U bit.
(get_valid_dis386): Roll back to APX condition.
* i386-opc.tbl: Remove ymm rounding support.
* i386-tbl.h: Regenerated.
Turns out the return value of parse_loongarch_dis_option acts as an
error code, and previously the function always signified failure with
a non-zero return value, making only the first disassembly option get
to take effect.
Fix by adding the missing `return 0`'s to the two success code paths.
Signed-off-by: WANG Xuerui <git@xen0n.name>
