"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.
One interesting observation is that successful RISC CPUs dont have a super simple ISA anymore. At least not in the frontend.
MIPS was notorious for having a simple ISA and RISCV is trying to mimick that to some extent.
But look at thumb2 for example and you will see complex encodings and even variable instruction width.
Back in the day, Alpha and HPPA were commonly used as examples of 'with all this extra stuff is it still RISC?'. These days, I think the CISC/RISC divide is largely an historical artifact.
I think the idea of simplicity is still relevant, but the problem is not as simple as (no pun) having a certain look to your ISA anymore. ISA transformed to something unrecognisable 2-3 steps into the pipeline, the rest of the CPU doesn't see much of the ISA.
Maybey we should abandon "reduced instruction set" and instead evaluate how ISA is suitable for out of order execution or speculative execution or backtracking and so on
Fair. Personally, I think the idea of simplicity is still relevant for pedagogy (as it always is), but one you rope in 'suitable for out of order execution or speculative execution or backtracking and so on' as criteria, 'simple' is harder to achieve (at least for practical commercial designs). YMMV.
ARM64 looked like an exercise in "what can we squeeze into a 32-bit instruction" the first time I examined it in detail; the various "load/store register pair" instructions are a great example of this. I would consider it even more difficult to decode than x86, and yet it's still nowhere near as dense as Thumb2 nor x86.
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.
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.
Note that RISC5 [1], a project created as a target for Wirth's Oberon compilers, is a different project from RISC-V [2], a project created at Berkeley which became what is currently the most popular open source 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.
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.
One interesting observation is that successful RISC CPUs dont have a super simple ISA anymore. At least not in the frontend.
MIPS was notorious for having a simple ISA and RISCV is trying to mimick that to some extent. But look at thumb2 for example and you will see complex encodings and even variable instruction width.
Back in the day, Alpha and HPPA were commonly used as examples of 'with all this extra stuff is it still RISC?'. These days, I think the CISC/RISC divide is largely an historical artifact.
I think the idea of simplicity is still relevant, but the problem is not as simple as (no pun) having a certain look to your ISA anymore. ISA transformed to something unrecognisable 2-3 steps into the pipeline, the rest of the CPU doesn't see much of the ISA.
Maybey we should abandon "reduced instruction set" and instead evaluate how ISA is suitable for out of order execution or speculative execution or backtracking and so on
Fair. Personally, I think the idea of simplicity is still relevant for pedagogy (as it always is), but one you rope in 'suitable for out of order execution or speculative execution or backtracking and so on' as criteria, 'simple' is harder to achieve (at least for practical commercial designs). YMMV.
ARM64 looked like an exercise in "what can we squeeze into a 32-bit instruction" the first time I examined it in detail; the various "load/store register pair" instructions are a great example of this. I would consider it even more difficult to decode than x86, and yet it's still nowhere near as dense as Thumb2 nor x86.
But thumb2 is dead. “Successful RISC CPUs” is aarch64. No thumb2.
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.
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.
here you go: https://gist.github.com/camel-cdr/bd5b197ab140ad6df259916df1...
This would make for a neat poster.
Yes. And: Fabric.
Shirt.
can someone do the same for RISC5?
Note that RISC5 [1], a project created as a target for Wirth's Oberon compilers, is a different project from RISC-V [2], a project created at Berkeley which became what is currently the most popular open source ISA.
[1] https://riskfive.com/RISC5_overview.htm
[2] https://riscv.org/
It is funny that RISC-V International moved to Switzerland in 2020 so now both projects can be found in the same place.
nah
dash is hard to type and vee is hard to pronounce
it is five and that's more convinient
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.