I wanted to extend a sincere apology for mistakenly spelling your name incorrectly in my previous email. Shiro B 于2024年3月11日周一 19:31写道： > Hi Andrew Binn, > > 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. > > 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). > 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 > > 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. > > Best regards > > > Andrew Dinn 于2024年3月11日周一 18:41写道： > >> Hi Shiro B, >> >> I believe a lot of the simulator code is based on work that was >> originally done by me when we used the simulator to port OpenJDK to run >> on AArch64. It was adapted by Phil Muldoon for use in gdb but a lot of >> the code still looks recognisable to me. I cannot properly answer all >> your questions but I can provide some background that might help. >> >> The original simulator was built to allow execution of AArch64 code >> generated by the OpenJDK JIT compiler before any hardware was available. >> So, it was based on a pre-release copy of the ARM ARM (ARM Architecture >> Reference Manual) and it only catered for the subset of the original >> instruction set that might be used during operation of conventional >> userspace application. >> >> It did cover all the standard GPR- and FPR-based instructions. I think >> it may also have supported a small subset of Neon vector instructions. >> It did not cater for instructions, and associated registers, that would >> only be needed during system bootstrap (e.g. only a few move to/from >> system register options are supported). It also does not correctly >> implement the AArch64 memory model - the original sim provided a >> per-thread memory cache to simulate a local memory buffer but it was >> nothing like the real thing. So, memory reads and writes operate using >> host memory semantics (e.g. TSO on x86). >> >> I am not certain but I think the version currently in the gdb tree has >> been updated to allow for extra Neon vector instructions that were not >> in the original decode/execute tree. I don't think it has been updated >> to cater for the few recent additions to the instruction set, nor to >> allow for SVE. I cannot say exactly what is implemented now. It looks >> like it still only really addresses userspace programs. >> >> I can tell you how to find out fairly quickly and easily what parts of >> the instruction set are implemented. Start by looking at routine >> *aarch64_decode_and_execute* in file simulator.c. It gets called from >> *aarch64_step/run* to decode and execute a single instruction. The >> decode does a recursive descent through groups and subgroups of >> instructions, based on a hierarchy of discriminant bits. >> >> So, the top level dispatch is on bits [28..25]. Within each top level >> group different bit patterns are used to do the next dispatch and so on. >> For example, instructions in top level groups GROUP_DPIMM_1000 and >> GROUP_DPIMM_1001 are discriminated by looking at bits [25..23] (n.b. it >> may be obvious but just to spell it out -- the numbers in those top >> level enum tags indicate what value bits [28..25] have). >> >> The logic of this recursive dispatch is implemented by the functions in >> simulator.c with names in the format dexAAAAAA (A is an Alphabetic >> character). The corresponding top level and nested bit patterns they >> rely on are defined by enums with names in the format DispatchAAAA in >> file decode.h. The function and enum names should match up. >> >> So, if you follow through each of these functions and associated nested >> bit patterns you can find all the instructions in a given family and >> subfamily that are implemented by the sim. Likewise if you want to see >> if an instruction is implemented then you need to read off the bit >> patterns from the top level on downwards to place it in a family and >> subfamilies. When you reach the bottom of the dexAAAA tree you will find >> out whether it is catered for or treated as an unknown instruction. >> >> Sorry that does not answer all your questions. Hopefully the comments in >> the code will still help you identify what is supported and how. If they >> are not enough then I may be able to answer specific queries. However, >> since I wrote the original code 12 years ago I'm not sure I will be able >> to remember all the details. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> >> >> On 11/03/2024 03:34, Shiro B via Gdb wrote: >> > Dear GDB Mailing List, >> > >> > I hope this message finds you well. I am reaching out to express my keen >> > interest in the AArch64 simulator included within GDB. (the one in >> > [binutils-gdb.git]/sim/aarch64/) >> > >> > Despite my efforts, I have encountered difficulty in locating detailed >> > documentation or introductions that shed light on several aspects of >> this >> > simulator. >> > >> > My inquiries primarily revolve around its capabilities and limitations >> with >> > regard to the ARM64 instruction set. >> > >> > Specifically, I am eager to understand: >> > >> > 1. Which ARM64 instructions are supported by the AArch64 simulator? >> > 2. Which version of the ARM standard does it adhere to? like v8 v8.1...? >> > 3. Are there any extensions to the instruction set that the simulator >> > supports? like pauth, crypto, neon, etc >> > 3. Could you provide details on any instructions that are explicitly not >> > supported? >> > 4. Is the simulator limited to user-mode instructions, or does it offer >> > broader functionality? >> > 5. Lastly, I would appreciate insights into any known issues, >> limitations, >> > or scenarios where the AArch64 simulator may not be suitable for use. >> > >> > I believe understanding these aspects will greatly enhance my ability to >> > utilize the AArch64 simulator effectively within GDB for development and >> > testing purposes. Your guidance and any available documentation or >> > resources on this topic would be immensely valuable. >> > >> > Thank you for your time and assistance. I look forward to your response >> and >> > any information you can share. >> > >> > Best regards >> > >> >>