4 ms·

Because individual instructions doing the same thing are faster. Though it's especially slow because it's microcoded and is left just for backwards compatibilit

Because individual instructions doing the same thing are faster. Though it's especially slow because it's microcoded and is left just for backwards compatibility and not trying to be fast. So modern CPUs are good at reordering, predicting branches, etc., for simple instructions and no extra silicon needs to be wasted to duplicate that. And encoding space is limited as well.

userbinator 11y ago
If individual instructions are faster, that means the instruction decoder isn't as good as it should be. BOUND wasn't fast because it didn't get any use, and it didn't get any use because people thought it was slow... but now that the usefulness of this instruction is apparent, it seems to me that they should make the decoder issue the necessary uops and make it at least as fast as the (bigger, more cache-wasting) sequence of simpler instructions. Instructions like MOVS and STOS used to be slower than the equivalent series of simple instructions, but now they're much faster. Even the more obscure and far less useful BCD arithmetic instructions have been made on-par with a longer series of equivalent instructions[1] so not doing the same for the much more useful BOUND is... unusual. The amount of silicon needed to implement MPX (which includes several new instructions) seems far more than it'd take to make a BOUND decode faster. [1] https://news.ycombinator.com/item?id=8477585 https://news.ycombinator.com/item?id=8477585
- dfox 11y ago
  BOUND didn't get much of an use because it is useful only for bounds checking of the "dump core if outside" kind.
  - mkesper 11y ago
    Why? (Honest question).
    - unwind 11y ago
      Because the instruction raises a software exception if the test fails. This is a rather heavy-handed reaction, although I guess it kind of makes sense from the instruction's point of view I guess. Of course a language runtime based on using this instruction needs to capture the exception and handle it, core-dumping need not be the only option at that point.
      - stassats 11y ago
        Part of the issue is that the interrupt number, 5, is hard-wired. So there really was no need to keep it alive.
        userbinator 11y ago
        Divide-by-zero has always been interrupt 0, and the page fault is at #14, and that hasn't been problematic... BOUND does raise an exception if it fails but I think that's a good thing - if code is doing array bounds-checking, OOB accesses are very likely to be a bug (and possible security vulnerability) so aborting execution by default is the right thing to do.

userbinator 11y ago

If individual instructions are faster, that means the instruction decoder isn't as good as it should be. BOUND wasn't fast because it didn't get any use, and it didn't get any use because people thought it was slow... but now that the usefulness of this instruction is apparent, it seems to me that they should make the decoder issue the necessary uops and make it at least as fast as the (bigger, more cache-wasting) sequence of simpler instructions. Instructions like MOVS and STOS used to be slower than the equivalent series of simple instructions, but now they're much faster. Even the more obscure and far less useful BCD arithmetic instructions have been made on-par with a longer series of equivalent instructions[1] so not doing the same for the much more useful BOUND is... unusual. The amount of silicon needed to implement MPX (which includes several new instructions) seems far more than it'd take to make a BOUND decode faster. [1] https://news.ycombinator.com/item?id=8477585 https://news.ycombinator.com/item?id=8477585

dfox 11y ago
BOUND didn't get much of an use because it is useful only for bounds checking of the "dump core if outside" kind.
- mkesper 11y ago
  Why? (Honest question).
  - unwind 11y ago
    Because the instruction raises a software exception if the test fails. This is a rather heavy-handed reaction, although I guess it kind of makes sense from the instruction's point of view I guess. Of course a language runtime based on using this instruction needs to capture the exception and handle it, core-dumping need not be the only option at that point.
    - stassats 11y ago
      Part of the issue is that the interrupt number, 5, is hard-wired. So there really was no need to keep it alive.
      - userbinator 11y ago
        Divide-by-zero has always been interrupt 0, and the page fault is at #14, and that hasn't been problematic... BOUND does raise an exception if it fails but I think that's a good thing - if code is doing array bounds-checking, OOB accesses are very likely to be a bug (and possible security vulnerability) so aborting execution by default is the right thing to do.