Comment on Why we don't have 128-bit CPUs
ulterno@lemmy.kde.social 4 months agoI 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.
wewbull@feddit.uk 4 months 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)
ulterno@lemmy.kde.social 4 months ago
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.
err… they are still instructions, right? And they are implemented. I don’t see why you would negate that from the number of instructions.
wewbull@feddit.uk 4 months 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.
ulterno@lemmy.kde.social 4 months 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.