[LLVMdev] Intel Memory Protection Extensions (and types question)
kcc at google.com
Tue Sep 10 02:28:15 PDT 2013
On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote:
> > How did you come with 320 bits?
> > 320=64*4+64, which is the size of the metadata table entry plus pointer
> Sorry, that should have been 192. The specification allows the metadata
> to be stored either in look-aside tables or explicitly managed.
Is it? Which specification are you referring to?
9) doesn't say anything like this. (Or does it?)
> The tables impose a very large storage space penalty, so are most likely
> to be used with C or similar language where it is difficult to modify the
> data layout. For languages where there is no requirement to maintain an
> ABI that interoperates with non-MPX code, the metadata can be stored inline
> when running in bounds-checked mode. I forgot that when using it in this
> mode you needed to store less metadata than when using the bound tables.
> > but why do you call this a fat pointer?
> Because that's what it is: a pointer + metadata
> > In MPX, the fat pointer never exists as a single entity.
> The pointer and metadata exist in separate registers, but single
> instructions (loads and stores) operate on the pointer + metadata.
Which MPX instructions do you mean here?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev