RFR: 8328998: Encoding support for Intel APX extended general-purpose registers

[Andrew Haley]

On Tue, 9 Apr 2024 19:44:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Add instruction encoding support for Intel APX extended general-purpose registers:
>> 
>> Intel Advanced Performance Extensions (APX) doubles the number of general-purpose registers, from 16 to 32. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html.
>> 
>> By specification, instruction encoding remains unchanged for instructions using only the lower 16 GPRs. For cases where one or more instruction operands reference extended GPRs (Egprs), encoding targets either REX2, an extension of REX encoding, or an extended version of EVEX encoding. These new encoding schemes extend or modify existing instruction prefixes only when Egprs are used.
>
> How can we be confident that the encoding is correct?  Would it be possible to write tests for this?  Maybe one that disassembles it and compares the result to a 3rd party disassembler offline or in-process hsdis?

> Thank you @dean-long for the comment. I agree, tests are needed. Up to this point we have not had a separate formal tool to test encoding of x86. I did a lot of manual testing by adding loops that used r0-r31in different addressing patterns. I put these in a stub file that would be compiled by hotspot but not executed. I manually compared the disassembly of that against the output of similar assembly included in a small C program and run on the SDE. This worked pretty well for debugging but the manual aspect of it makes it error-prone and it takes a lot of time, too much time if iterating an implementation.
> 
> Subsequent pull requests will add encoding support for additional APX instructions (e.g. those using New Data Destination). Maybe one of these PRs can include a tool for testing instruction encoding for APX features. What do you think?

When we wrote the AArch64 port, there was no available hardware to test it on. So, we wrote a simulator to test it. However, we ran the risk that if our understanding of instruction encoding was wrong, our assembler and our simulator might appear to work correctly when used together, but the result would not run on real AArch64 hardware once it arrived.
So, as well as a simulator for the architecture, we verified the internal HotSpot assembler by checking its encoding against GNU `as`. See /test/hotspot/gtest/aarch64, where a Python program generates source for both the HotSpot internal assembler and GNU `as`. I strongly suggest you do something similar.
 (As a matter for the historical record, this did work. The test found several encoding bugs. Once we got the first real AArch64 hardware, the port worked almost immediately.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18476#issuecomment-2092579988