Any thoughts on how the upcoming hardware supported bounds checking from Intel will affect D?

http://en.wikipedia.org/wiki/Intel_MPX

Chapter 9 in:

https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

On Monday, 15 December 2014 at 16:30:14 UTC, Ola Fosheim Grøstad wrote:
> Any thoughts on how the upcoming hardware supported bounds checking from Intel will affect D?
>
> http://en.wikipedia.org/wiki/Intel_MPX
>
> Chapter 9 in:
>
> https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

Interesting, given that bounds checking support is an old feature

http://x86.renejeschke.de/html/file_module_x86_id_18.html

If I remember my Assembly days in the 90's BOUND was slower than doing the check explicitly.

I guess now it is way faster and the MMU is doing it instead.

--
Paulo

2014-12-15 16:55 GMT-02:00 Paulo Pinto via Digitalmars-d < digitalmars-d@puremagic.com>:
>
> On Monday, 15 December 2014 at 16:30:14 UTC, Ola Fosheim Grøstad wrote:
>
>> Any thoughts on how the upcoming hardware supported bounds checking from Intel will affect D?
>>
>> http://en.wikipedia.org/wiki/Intel_MPX
>>
>> Chapter 9 in:
>>
>> https://software.intel.com/sites/default/files/managed/ 0d/53/319433-022.pdf
>>
>
> Interesting, given that bounds checking support is an old feature
>
> http://x86.renejeschke.de/html/file_module_x86_id_18.html
>
> If I remember my Assembly days in the 90's BOUND was slower than doing the check explicitly.
>
> I guess now it is way faster and the MMU is doing it instead.
>


​Actually, MPX provides a complete infra-structure for bounds-checking, including special-purpose registers (4 of them), a bounds directory/tables for storing/loading linearized pointer addresses, specific instructions to independently make/check upper/lower bounds, and even modified versions of call/ret/jump.

​They are working in the ABI level so calling conventions can benefit from
it. Although MPX currently supports only statically allocated arrays, a
memory-protected version of glibc is on the way​:
https://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain

​I've tried out the MPX-enabled GCC version and it looks pretty cool. ​
--
​Leandro​

On Tuesday, 16 December 2014 at 06:18:10 UTC, Leandro T. C. Melo via Digitalmars-d wrote:

> including special-purpose registers (4 of them), a bounds directory/tables
> for storing/loading linearized pointer addresses, specific instructions to
> independently make/check upper/lower bounds, and even modified versions of
> call/ret/jump.

Yes, it is a very interesting move. It seems like Intel keeps focusing on adding features to cores rather than scaling up the number of cores. If this goes on, I think x86 will start to influence the design of languages and runtime capabilities.

Tying bounds to the address of the pointer seems to have implications for how one should structure programs too. I wonder how the avoid cache misses in the table lookup, though. I guess that is why they have modified instructions that modify the instruction pointer?

One of the interesting features of MPX is that you turn off MPX and then the CPU will treat MPX instructions as NOP instructions. So you can basically compile your server with MPX, and only turn it on when you run into trouble or when you have low load.

> ​They are working in the ABI level so calling conventions can benefit from
> it. Although MPX currently supports only statically allocated arrays, a
> memory-protected version of glibc is on the way​:
> https://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-extensions-intel-mpx-support-in-the-gnu-toolchain

Yes, they are building MPX support into malloc, I believe. So anything malloc'ed will be bounds-checkable when you turn on full MPX instrumentation.

> ​I've tried out the MPX-enabled GCC version and it looks pretty cool.

Did you run the MPX-enabled executable on an emulator?

On Monday, 15 December 2014 at 18:55:42 UTC, Paulo Pinto wrote:
> Interesting, given that bounds checking support is an old feature
>
> http://x86.renejeschke.de/html/file_module_x86_id_18.html
>
> If I remember my Assembly days in the 90's BOUND was slower than doing the check explicitly.

Yes, and the BOUND instruction is deprecated and not available in 64-bit mode. It was also rather primitive compared to MPX. MPX basically could make it possible for most C programs to bounds check pointers extensively, not only arrays. At least in debug builds.

> I guess now it is way faster and the MMU is doing it instead.

The instructions are explicit, so you need solid compiler support. But the lookup structure reminds me of how page-tables are structured. So I suppose Intel are leveraging the knowhow they have on MMU design when doing the implementation for MPX.

2014-12-16 10:30 GMT-02:00 via Digitalmars-d <digitalmars-d@puremagic.com>:
>
> Did you run the MPX-enabled executable on an emulator?
>

Exactly, you need to link the code against an MPX runtime and run it through Intel's SDE.

--
Leandro

On Tuesday, 16 December 2014 at 13:37:05 UTC, Leandro T. C. Melo via Digitalmars-d wrote:
> Exactly, you need to link the code against an MPX runtime and run it through Intel's SDE.

Sounds like fun! I guess it is possible to play with ADX (multi precision integers) that came with Broadwell using SDE as well.

Seems like Intel is investing heavily into support high level features in hardware. I assume this is to keep JVM/CIL oriented CPUs from taking their markets and raising the bar for AMD. Maybe we will see Intel pushing for more and more advanced hardware features in the coming years. Could be interesting.