www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Intel MPX

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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
Dec 15 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Dec 15 2014
next sibling parent reply "Leandro T. C. Melo via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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=C3=B8stad wro=


te:

 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 th=


e

 check explicitly.

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



=E2=80=8BActually, MPX provides a complete infra-structure for bounds-check=
ing,
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.

=E2=80=8BThey are working in the ABI level so calling conventions can benef=
it from
it. Although MPX currently supports only statically allocated arrays, a
memory-protected version of glibc is on the way=E2=80=8B:
https://software.intel.com/en-us/blogs/2013/07/22/intel-memory-protection-e=
xtensions-intel-mpx-support-in-the-gnu-toolchain

=E2=80=8BI've tried out the MPX-enabled GCC version and it looks pretty coo=
l.
=E2=80=8B
--
=E2=80=8BLeandro=E2=80=8B
Dec 15 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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?
Dec 16 2014
parent reply "Leandro T. C. Melo via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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
Dec 16 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 16 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Dec 16 2014