[HN Gopher] Visualizing the ARM64 Instruction Set (2024)
       ___________________________________________________________________
        
       Visualizing the ARM64 Instruction Set (2024)
        
       Author : userbinator
       Score  : 70 points
       Date   : 2026-02-15 23:20 UTC (3 days ago)
        
 (HTM) web link (zyedidia.github.io)
 (TXT) w3m dump (zyedidia.github.io)
        
       | kinow wrote:
       | 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.
        
         | Someone wrote:
         | 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.
        
         | camel-cdr wrote:
         | here you go: https://gist.github.com/camel-
         | cdr/bd5b197ab140ad6df259916df1...
        
       | saagarjha wrote:
       | This would make for a neat poster.
        
         | AnthonBerg wrote:
         | Yes. And: Fabric.
         | 
         | Shirt.
        
       | NooneAtAll3 wrote:
       | can someone do the same for RISC5?
        
         | jecel wrote:
         | 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.
        
       | isa_lover_2026 wrote:
       | 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.
        
       | vardump wrote:
       | So much empty space in the ISA.
        
         | pm215 wrote:
         | 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.
        
       | pm215 wrote:
       | 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.
        
       | throwa356262 wrote:
       | 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.
        
         | kjs3 wrote:
         | 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.
        
           | throwa356262 wrote:
           | 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
        
       ___________________________________________________________________
       (page generated 2026-02-19 23:02 UTC)