<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 1:47 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 10 Sep 2013, at 10:28, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>

<br>
><br>
><br>
><br>
> On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br>
> On 10 Sep 2013, at 10:13, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
><br>
> > How did you come with 320 bits?<br>
> > 320=64*4+64, which is the size of the metadata table entry plus pointer size,<br>
><br>
><br>
><br>
> Sorry, that should have been 192.  The specification allows the metadata to be stored either in look-aside tables or explicitly managed.<br>
><br>
> Is it? Which specification are you referring to?<br>
> <a href="http://download-software.intel.com/sites/default/files/319433-015.pdf" target="_blank">http://download-software.intel.com/sites/default/files/319433-015.pdf</a> (chapter 9) doesn't say anything like this. (Or does it?)<br>

<br>
</div>See the BNDMOV instruction, which allows the bounds to be explicitly loaded and stored to bounds registers.  Contrast with BNDLDX / BNDSTX, where the location is implicit.  The BNDMOV instruction is also used for stack spills of the bounds registers.  This allows MPX to be used for range checking in a similar way to the Thumb-2EE extensions.<br>
</blockquote><div><br></div><div>Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is not the real intention of the MPX developers</div><div>since a fat pointer will break all ABIs, and MPX tries to preserve them.</div>
<div>I don't think we need fat pointers to support MPX in LLVM -- it will complicate the implementation beyond necessity. (My 2c)</div><div>All we need is to represent a 128-bit type that will live in BNDx registers.</div>
<div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>>  The pointer and metadata exist in separate registers, but single instructions (loads and stores) operate on the pointer + metadata.<br>
> Which MPX instructions do you mean here?<br>
<br>
</div>Ah, sorry, I was confusing MPX with one of the other HardBound-like schemes here.  In MPX, you must implicitly insert the BNDCU and BNDCL instructions.  I would expect that you'd want to model the BNDCU + BNDCL + MOV sequence as a single pseudo for as long as possible to ensure that the bounds checks were performed at the correct time and not elided, but they are separate instructions (although if they don't do micro-op fusion on the sequence I'd be shocked, since you can trivially do both bounds checks in a single cycle and speculatively enqueue the memory operation with enough time to cancel it if it turned out that the bounds checks should trap).<br>

<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div></div>