1

I found the quote below online. Is it possible to disable a general protection exception when a pointer isn't in canonical address form? I was thinking for my app it would be so nice if I can use the high 4bits of a pointer to hold extra data (for example if a node is red or black in a red-black tree)

Although implementations might not use all 64 bits of the virtual address, they check bits 63 through the most-significant implemented bit to see if those bits are all zeros or all ones. An address that complies with this property is said to be in canonical address form. If a virtual-memory reference is not in canonical form, the implementation causes a general-protection exception or stack fault

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Eric Stotch
  • 141
  • 4
  • 19
  • 3
    No, AFAIK there's no MSR or control-register bit to ask the CPU to disable that check, or someone would have mentioned it as an alternative to masking away the high or low bits you use for tagged pointers in one of the existing Q&As about it: [Can I use some bits of pointer (x86\_64) for custom data? And how if possible?](https://stackoverflow.com/q/31522582) / [Using the extra 16 bits in 64-bit pointers](https://stackoverflow.com/q/16198700) – Peter Cordes Nov 24 '20 at 05:34

1 Answers1

4

I don't believe so. I've never heard of such a feature, and skimming the Intel manuals for matches for "canonical" doesn't turn up anything. I think it's essentially hard-wired.

Note that the architecture reserves the right for future implementations to use more bits, e.g. Intel's 5-level paging CPUs moved from 48- to 57-bit canonical addresses. So if this were possible, any program that used too many of the high bits would risk being incompatible with those future CPUs. The CPU makers have an interest in ensuring forward compatibility, and therefore they would have a disincentive to provide the feature you want.

Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
  • 4
    In fact. the only reason for the canonical checks is so they can expand the virtual address space without breaking programs. They learned from other processors that had expanded address spaces, like the 68000 series' move from a 24-bit to 32-bit address space which caused significant compatibility problems. – Ross Ridge Nov 24 '20 at 07:48