Intel Preparing Linear Address Masking Support (LAM)

[phoronix]

Phoronix: Intel Preparing Linear Address Masking Support (LAM)

A few days ago there was a glibc commit mentioning Intel "LAM" and now the updated Intel documentation sheds more light on this forthcoming processor feature...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-LAM-Glibc

[PluMGMK]

I thought enforcing canonicity was a conscious engineering decision to allow expansion of the address space in future architecture revisions in a backwards-compatible manner. Have Intel now decided to undo that decision?

[cesarb]

This is something 64-bit ARM had since the beginning; there, it's called Top Byte Ignored, and Linux always enables that flag (TCR_EL1.TBI0).

I don't think it will work as well on Intel, since software has to worry about compatibility both with older processors and with AMD. With 64-bit ARM, it was there since the beginning (and enabled on Linux since 3.12 seven years ago), so there's much less worry about compatibility.

Have Intel now decided to undo that decision?

That decision was from AMD, not Intel; it remains to be seen whether AMD will follow Intel in undoing that decision.

[PluMGMK]

That decision was from AMD, not Intel; it remains to be seen whether AMD will follow Intel in undoing that decision.

I knew that, and I had a feeling that that might have something to do with it. Still, Intel went along with it for over 15 years, and in the middle of it brought in five-level paging, so it is kind of a U-turn for them too…

[willmore]

Anyone remember the graceful transition that Mac's had when they went from 24 bit to 32 bit addressing? How about ARM when they did it? Yeah, those were bad times.

[OneTimeShot]

Anyone remember the graceful transition that Mac's had when they went from 24 bit to 32 bit addressing? How about ARM when they did it? Yeah, those were bad times.

Yup - Amiga 1200 had this problem when the 68020 came in. Surely no one will ever have more than 16Mb? Let's use those wasted bits for something else!

[dev_null]

What I worry about is that now as during 8086 times there can be 2 different pointers which point to the same address. That is something like:

int a = 15;
int * pa = &a;
int * pb = &a;
pb = (int *)(0x5000000000000000ull | (unsigned long long)pb);

At this point pb is:
- still a valid pointer, which points to 'a' variable
- comparison like:

if (pa == pb)

will fail.

With LAM such a chaos may spread.
Obviously right now it is also possible to create two pointers which point to the same physical address, but in a regular program nobody uses it because it is hard (you have to use mmap and a special kind of memory).

But yes, having 7 or 8 bits free in pointer is cool, you can use them as boolean flags or even as a counter of pointer users.

[flashmozzg]

I thought enforcing canonicity was a conscious engineering decision to allow expansion of the address space in future architecture revisions in a backwards-compatible manner. Have Intel now decided to undo that decision?

I guess they've decided that no one will ever need/use more than 57 of address space (what's that, 128 petabytes?), which is not a bad assumption to make - I highly doubt we'll be still using x86 by the time we reach that point xD

[PluMGMK]

Well, you never know… These assumptions have ways of coming back and biting people…

[willmore]

I guess they've decided that no one will ever need/use more than 57 of address space (what's that, 128 petabytes?), which is not a bad assumption to make - I highly doubt we'll be still using x86 by the time we reach that point xD

Of contiguous storage? No, probably not any time soon. But sparse address spaces are a thing especially in large NUMA systems. Then again, those systems would just not enable this 'feature', I guess. Given their issues with processor flaws in the last decade, I would think they'd avoid things like this which could easily come back to bite them.