From: Andrew Dinn <adinn@redhat.com>
To: Shiro B <laodabaicai@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Inquiry on AArch64 Simulator in GDB
Date: Mon, 11 Mar 2024 15:24:52 +0000 [thread overview]
Message-ID: <f7819a19-1f6d-dd61-acd9-76087fca4941@redhat.com> (raw)
In-Reply-To: <CAC3JbXfzH+-r9ABzELTM0sA9=AfaqozDa2RNh=XpSLwr_H7nTQ@mail.gmail.com>
On 11/03/2024 11:31, Shiro B wrote:
> Thank you very much for your comprehensive response regarding the
> AArch64 simulator. A userspace simulator is all I need, and this seems
> will be very helpful to my project.
Glad to be able to help.
> During my exploration and testing, I believe I may have stumbled upon a
> bug related to the UMINV instruction, as detailed in the ARM
> documentation
> (https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en <https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en>). According to ARM's specifications, it appears that after comparing and identifying the minimum value in a vector, the result should be stored in a floating-point/vector register, rather than a general-purpose register. The relevant code can be found here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#l4482 <https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#l4482>
>
> Admittedly, my familiarity with ARM64, especially SIMD instructions, is
> not very extensive. However, through testing, I've noticed that the
> simulation's outcome for this instruction indeed differs from that of an
> actual CPU.
>
> Could you please take a look at this observation and provide your
> insights? I'm keen to understand whether this discrepancy could be
> attributed to my limited understanding or if it indeed points to a
> potential oversight in the simulator's implementation of the UMINV
> instruction (and also UMAXV, SMINV, SMAXV).
>
> Thank you once again for your invaluable feedback and for considering my
> query. I look forward to your expert opinion on this matter.
Yes, I agree that is an error. The spec clearly states that all four
instructions should place the result in the "SIMD&FP destination
register encoded in the "Rd" field". Well done for spotting it.
regards,
Andrew Dinn
-----------
prev parent reply other threads:[~2024-03-11 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-11 3:34 Shiro B
2024-03-11 10:41 ` Andrew Dinn
2024-03-11 11:31 ` Shiro B
2024-03-11 11:36 ` Shiro B
2024-03-11 15:24 ` Andrew Dinn [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7819a19-1f6d-dd61-acd9-76087fca4941@redhat.com \
--to=adinn@redhat.com \
--cc=gdb@sourceware.org \
--cc=laodabaicai@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).