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)
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.
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.
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)
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.
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.