4 ms·

> bounds checking in hardware. What. That's a horrible idea. Not only would that require your hardware to understand abstractions several layers above what it

> bounds checking in hardware. What. That's a horrible idea. Not only would that require your hardware to understand abstractions several layers above what it actually operates on, it would also mean it'd have to check bounds of - for example - an array on every instruction accessing it. That is something compilers can do at more strategic places. Please keep that complexity out of my CPUs, they're buggy enough already. At least with software we can fix issues later, which isn't a given with hardware.

DblPlusUngood 8y ago
Turns out the x86 already has some bounds checking support; see chapter 17 in volume 1 of Intel's developer manuals and the BOUND and BND* instructions.
- hyperman1 8y ago
  In fact they were removed in 64 bit mode. Same for INTO
marcosdumay 8y ago
LoadAddressIfSmallerThan makes for a long opcode name, but it doesn't look much more complex than your usual load. The added complexity is negligible. And, of course, the added complexity of doing that in two instructions is also negligible. The entire problem seems to be that arrays are on a more abstract level than C operates. It looks like entirely a language problem.
pjc50 8y ago
Having the CPU do the checking within an instruction saves you instruction issue events. ARM have an interesting solution to this, pointer authentication: https://news.ycombinator.com/item?id=14479438 https://news.ycombinator.com/item?id=14479438 > several layers above what it actually operates on The instruction set is something of an abstraction bottleneck - C is tied to machines that look something like a PDP-11, while a lot of the stuff that the machine is doing is invisible at the instruction set layer.
- makomk 8y ago
  Pointer authentication is not a form of bounds checking. It solely exists to prevent a malicious attacker using a bug to directly overwrite pointers (and in practice, it's mostly limited to return addresses right now). Code which does buggy pointer arithmetic will still create valid pointers to data outside the intended buffer.

DblPlusUngood 8y ago

Turns out the x86 already has some bounds checking support; see chapter 17 in volume 1 of Intel's developer manuals and the BOUND and BND* instructions.

hyperman1 8y ago
In fact they were removed in 64 bit mode. Same for INTO

marcosdumay 8y ago

LoadAddressIfSmallerThan makes for a long opcode name, but it doesn't look much more complex than your usual load. The added complexity is negligible. And, of course, the added complexity of doing that in two instructions is also negligible. The entire problem seems to be that arrays are on a more abstract level than C operates. It looks like entirely a language problem.

pjc50 8y ago

Having the CPU do the checking within an instruction saves you instruction issue events. ARM have an interesting solution to this, pointer authentication: https://news.ycombinator.com/item?id=14479438 https://news.ycombinator.com/item?id=14479438 > several layers above what it actually operates on The instruction set is something of an abstraction bottleneck - C is tied to machines that look something like a PDP-11, while a lot of the stuff that the machine is doing is invisible at the instruction set layer.

makomk 8y ago
Pointer authentication is not a form of bounds checking. It solely exists to prevent a malicious attacker using a bug to directly overwrite pointers (and in practice, it's mostly limited to return addresses right now). Code which does buggy pointer arithmetic will still create valid pointers to data outside the intended buffer.