• wewbull
    link
    fedilink
    English
    arrow-up
    5
    ·
    4 days 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
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 days 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
        link
        fedilink
        English
        arrow-up
        2
        ·
        2 days 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
          link
          fedilink
          English
          arrow-up
          0
          ·
          2 days 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.