The Alpha AXP is natively a 64-bit processor, but Windows NT for Alpha AXP treated it as a 32-bit processor. How is that possible?

The Alpha AXP registers are full 64-bit registers, and you are welcome to use all 64 bits to perform your computations, in the same way that you are welcome to use the 32-bit registers of the x86 even when the processor is in 16-bit mode.

The 32-bit-ness of the operating system comes into play when it comes to memory access. Although the address space is 64 bits, Windows NT uses only 4GB of it. It splits the memory down the middle, with the lower 2GB of memory at addresses 0x00000000`00000000 through 0x00000000`7FFFFFFF, and the upper 2GB of memory at addresses 0xFFFFFFFF`80000000 through 0xFFFFFFFF`FFFFFFFF.

It is no accident that this split exactly matches the Alpha AXP’s canonical format for 32-bit integers. It means that the code can truncate all addresses to the lower 32 bits, and then sign-extend the values to recover the original pointers. Sign-extending 32-bit values to 64-bit values is a common operation on the Alpha AXP, and it generally happens “for free”.

We saw earlier that there is some weirdness in calculating constants near the 2GB boundary, and Windows NT finesses the problem by simply declaring those addresses off-limits.

The fact that the processor is still a 64-bit processor means that you can carve out memory and stick it in the address space that is otherwise going to waste. That’s what Very Large Memory (VLM) does. You can use functions like Virtual­Alloc­Vlm to allocate memory, with the additional note that, “Hey, like, you can put this memory anywhere in the 64-bit address space. You don’t have to limit yourself to the 32-bit-compatible portion of the address space.”

Of course, your code had to remember to preserve all 64 bits of these addresses, and to use the full 64-bit value as a memory address. I don’t know if any compilers supported 64-bit pointers on Alpha AXP, but if you did, then you had 8 terabytes of address space to play with.