search for: bndcl

...nd metadata exist in separate registers, but single instructions (loads and stores) operate on the pointer + metadata. > Which MPX instructions do you mean here? 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 fusio...

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > 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 > size, > > > Sorry, that should have been 192. The specification allows the

...eparate registers, but single > instructions (loads and stores) operate on the pointer + metadata. > > Which MPX instructions do you mean here? > > 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'...

On 10 Sep 2013, at 12:13, Kostya Serebryany <kcc at google.com> wrote: > Well, ok, you can treat this as a 192-bit fat pointer, but AFAICT this is not the real intention of the MPX developers > since a fat pointer will break all ABIs, and MPX tries to preserve them. MPX is an implementation of the HardBound concept from UPenn, where this was a design goal (see also their 'low-fat