"The specification describes bits as combinations of 0, 1, and x, but also sometimes includes (0) and (1). I’m not sure what the parenthesized versions mean"
the answer is that the (0) and (1) are should-be-zero and should-be-one bits: if you set them wrongly then you get CONSTRAINED UNPREDICTABLE behaviour where the CPU might UNDEF, NOP, ignore that you set the bit wrongly, or set the destination register to garbage. In contrast, plain 0 and 1 are bits that have to be that way to decode to this instruction, and if you set them to something else then the decode will take you to some other instruction (or to UNDEF) instead.
Where instructions end up in this visualization depends heavily on the way instructions get encoded.
Because of that, I don’t think this visualization is useful for comparing instruction sets.
As an extreme example, take the ARM64 instruction set, but change the ordering of bits. That would completely change the visualization.
You might get something halfway informative by searching for the most similar image across all possible bit permutations in the instruction set. 64! is large, but that may be doable because hill climbing will (somewhat) work.
I don’t think it is desired, though. A good visualization starts with the question what you want to visualize, and chances are this isn’t the best way to visualize that answer.
For x86 there is sandpile.org, the probably densest human representation of the ISA, especially when it comes to the opcode tables.
Is there something comparable for ARM64? Basically, a landing page from which everything is just one click away, plus scrolling or a quick Ctrl-F search.
This is an important ISA feature -- an instruction encoding that is wasteful of its encoding space is one that has no room for future new instructions (or which has to encode the new instructions in complicated ways to fit in whatever tiny "holes" are left in the encoding space).
The old 32-bit Arm encoding had this problem, partly because of the "all instructions are conditional" feature. Even after the clawback of the "never" condition that wasted 1/16 of the available instruction encoding space as NOPs, it was tricky to find places to put new features.
On the tangential question in the post:
"The specification describes bits as combinations of 0, 1, and x, but also sometimes includes (0) and (1). I’m not sure what the parenthesized versions mean"
the answer is that the (0) and (1) are should-be-zero and should-be-one bits: if you set them wrongly then you get CONSTRAINED UNPREDICTABLE behaviour where the CPU might UNDEF, NOP, ignore that you set the bit wrongly, or set the destination register to garbage. In contrast, plain 0 and 1 are bits that have to be that way to decode to this instruction, and if you set them to something else then the decode will take you to some other instruction (or to UNDEF) instead.
Cool idea, and agree with this sentence in the final paragraph
> It would be cool to make a similar visualization for RISC-V and compare it with ARM64.
Or even compare a subset of the instruction set to see what's missing on different archs.
Where instructions end up in this visualization depends heavily on the way instructions get encoded.
Because of that, I don’t think this visualization is useful for comparing instruction sets.
As an extreme example, take the ARM64 instruction set, but change the ordering of bits. That would completely change the visualization.
You might get something halfway informative by searching for the most similar image across all possible bit permutations in the instruction set. 64! is large, but that may be doable because hill climbing will (somewhat) work.
I don’t think it is desired, though. A good visualization starts with the question what you want to visualize, and chances are this isn’t the best way to visualize that answer.
For x86 there is sandpile.org, the probably densest human representation of the ISA, especially when it comes to the opcode tables.
Is there something comparable for ARM64? Basically, a landing page from which everything is just one click away, plus scrolling or a quick Ctrl-F search.
So much empty space in the ISA.
This is an important ISA feature -- an instruction encoding that is wasteful of its encoding space is one that has no room for future new instructions (or which has to encode the new instructions in complicated ways to fit in whatever tiny "holes" are left in the encoding space).
The old 32-bit Arm encoding had this problem, partly because of the "all instructions are conditional" feature. Even after the clawback of the "never" condition that wasted 1/16 of the available instruction encoding space as NOPs, it was tricky to find places to put new features.
can someone do the same for RISC5?
This would make for a neat poster.