• @ulterno
    link
    English
    -15 months ago

    I see it as the number of possible instructions.

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

    CC BY-NC-SA

    • @wewbull@feddit.uk
      link
      fedilink
      English
      55 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
        link
        English
        05 months 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.

        • @wewbull@feddit.uk
          link
          fedilink
          English
          25 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
            link
            English
            05 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.