4 ms·
I think the GP was probably thinking of INTO(0xCE). https://en.wikipedia.org/wiki/INT_(x86_instruction)#INTO https://en.wikipedia.org/wiki/INT_(x86_instruction
by gopalv 6y ago
I think the GP was probably thinking of INTO(0xCE).
https://en.wikipedia.org/wiki/INT_(x86_instruction)#INTO https://en.wikipedia.org/wiki/INT_(x86_instruction)#INTO
The bounds-checking was MPX, I think.
> Another extremely useful instruction deleted from x86-64 tested if an array access was in bounds.
https://en.wikipedia.org/wiki/Intel_MPX#Extensions https://en.wikipedia.org/wiki/Intel_MPX#Extensions
- bleepblorp 6y agoI was thinking of BOUND[0] rather than MPX. It's a much lighter solution than MPX and didn't require OS support. [0] https://hjlebbink.github.io/x86doc/html/BOUND.html https://hjlebbink.github.io/x86doc/html/BOUND.html
- gsg 6y agoBOUND is pretty slow, and requires an odd start/end pair to be placed in memory. I don't see any reason that it would be better than the usual unsigned comparison + branch that languages with bounds checking tend to use. Besides, much of the difficulty with memory safety in C and C++ is the existence of pointers (or wrappers around them, like iterators), which do not come with an associated length. Length checking machinery can't help with that problem whether special instructions exist or not. In short, it's doubtful that the availability of these old instructions would make any difference to the practicality of bounds checking on modern x86 machines whatsoever.
- pjmlp 6y agoModern approaches take advantage of 64bit addressing modes to handle tagged pointers. The irony that we need a Lisp Machines solution to fix C and its derived languages.