Comment

Comment on Why we don't have 128-bit CPUs

I see it as the number of possible instructions.

As in, 8 bit 8085 had 2^8^ possible instructions, 32 bit ones had 2^32^ and already had enough possible combinations that we couldn’t come up with enough functions to fill the provided space.

CC BY-NC-SA

source

Sort:hotnew top

wewbull@feddit.uk ⁨1⁩ ⁨week⁩ ago
So “instruction encoding length”.

I don’t think that works though. For something like RISC-V, RV64 has a maximum 32-bit instruction encoding. For x86-64 those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)

source
- ulterno@lemmy.kde.social ⁨1⁩ ⁨week⁩ ago
  
  RV64 has a maximum 32-bit instruction encoding
  
  I kinda expected that to happen, since there’s already enough to fit all required functions. So yeah, even this is not a good enough criteria for bit rating.
  
  those original 8-bit intructions still exist, and take up a huge part of the encoding space, cutting the number of n-bit instructions to more like 2^(n-7)
  
  err… they are still instructions, right? And they are implemented. I don’t see why you would negate that from the number of instructions.
  
  source
  - wewbull@feddit.uk ⁨1⁩ ⁨week⁩ ago
    If the 8088 had used all but one 256 8-bit values as legal instructions, all your new instructions after that point would need to start with that unused value and then you can add a maximum of 256 instructions by using the next byte. End result is 511 instructions can be encoded in 16-bits.
    
    source
    ulterno@lemmy.kde.social ⁨1⁩ ⁨week⁩ ago
    Ah right! I forgot about that.
    
    So you either have to pad all instructions in all previous binaries, or reduce the amount of available instructions in the arch update.
    
    source