DougallI just published the first version of my illustrated SVE (ARMv9 SIMD) instruction list, with a truly absurd number of instruction diagrams and descriptions.
Check it out at https://dougallj.github.io/asil/
Alexander Monakov@dougall would be nice to make table headers sticky so they don't scroll out of view. It should be a matter of wrapping them in <thead> and adding
thead {
top: 0;
position: sticky;
}
to CSS. Do you want a pull request with that?
@amonakov Good suggestion, thanks! Probably best to avoid PRs, since the HTML is generated by scripts, but I'll look into it.
(Looks like I need to add the THEADs too)
Alastair Reid@dougall those diagrams are really nice. How much of it is automatically generated from the metadata and instruction specs and how much is done by hand?
Or, to put it another way, is there any information that would have made these easier to generate these diagrams?
Or, to put it another way, is there any information that would have made these easier to generate these diagrams?
@adreid Thanks! I'm a fan of your work on the specs :)
For each table row I manually list the instructions (e.g. "zip" -> zip1_z_zz, zipq1_z_zz, zipq2_z_zz). This is used to automatically populate the columns for the supported sizes from the spec. I automatically cross-match this with the SIMD intrinsics data (https://developer.arm.com/architectures/instruction-sets/intrinsics/), and I scan/pattern-match the starts of the ASL to automatically find the requirements (e.g. "HaveSVE() && HaveSVE2BitPerm() && NonStreamingSVEEnabled()").
@adreid The diagrams and descriptions aren't automated based on the specification (except for the page title, and the link to the documentation.) The ASL was extremely useful, and it's likely that the majority of simpler instructions could have been done by symbolic execution of the ASL, and it could have been a starting point for more complex instructions. It'd be fun to try this, but I'm not confident in my ability to pull it off.
@adreid (I was also thinking of these as "study notes" – part of the goal was to spend time thinking about each instruction to improve my understanding.)
@adreid One maybe-practical change I'd consider would be pulling the instrinsics data into the machine-readable-specs.
If I were to use symbolic execution, I think one of the trickier parts would be broadcasts, like in SUDOT above. Specifying these in terms of a broadcast function, followed by an element-wise operation might be preferable? But I'd want to try the symbolic execution approach before recommending something like that.
@dougall thanks for the explanation.
I think the symbolic execution approach would work well. And probably not too hard to implement based on the interpreter in ASLi.
I think the symbolic execution approach would work well. And probably not too hard to implement based on the interpreter in ASLi.
@dougall I know that the Intel intrinsic specs are indexed by the unique name of the instruction form. https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#ig_expand=0 and the XED database connects the instruction form with its binary encoding
https://intelxed.github.io and the x86 spec I’m working on gives the instruction semantics (not released yet)
https://intelxed.github.io and the x86 spec I’m working on gives the instruction semantics (not released yet)
@dougall and I came across some pages that link arm intrinsics with instructions.
https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#widening-addition
https://developer.arm.com/architectures/instruction-sets/intrinsics/vaddl_s8
Hopefully there is a machine readable version of this data - but scraping the html wouldn’t be too painful if not.
https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#widening-addition
https://developer.arm.com/architectures/instruction-sets/intrinsics/vaddl_s8
Hopefully there is a machine readable version of this data - but scraping the html wouldn’t be too painful if not.