> If you allocate a chunk on the heap with 8-byte alignment, then you can throw away the lowest 3 bits of precision, and then you can address 32GB with a 32-bit

> If you allocate a chunk on the heap with 8-byte alignment, then you can throw away the lowest 3 bits of precision, and then you can address 32GB with a 32-bit pointer. This part is totally doable, and in fact it's one of the pointer compression modes built into the JVM: https://shipilev.net/jvm/anatomy-quarks/23-compressed-references/ https://shipilev.net/jvm/anatomy-quarks/23-compressed-refere... For C++, it's a really interesting thought experiment, but in practice there are a few rough edges: 1. Your debugging tools will probably struggle to interpret compressed pointers. 2. You'll need to roll your own containers too. Otherwise, vectors, strings, maps, smart pointers, etc. will still use 64-bit pointers. In my experience, containers account for most pointers in a modern C++ code base. 3. _Technically_, the representation of null pointers is implementation-defined, so truncating to 32 bits and then zero-extending is not portable: it could convert a null pointer to a non-null pointer. In practice it doesn't matter though, since every modern target uses a zero bit pattern for null pointers.