5 ms·

It's funny how they targeted 32 bit x86 instead of just going straight for 64 bit. I wonder what drove that decision.

icedchai 6y ago
They didn't. It's x86_64 if you look at the startup screen.
johnklos 6y ago
Only half joking - "x86" refers to 32 bit, and: "Since the stack and static data on x86 is still allocated in 32-bit address space, a 32-bit pointer is sufficient to point to them." It seems they're still expecting a lot of VAX users to migrate.
- fredoralive 6y ago
  If x86 refers to 32 bit, what family do the 8086/88/186/286 belong to? 8080_16? :-) I do suspect as time goes by x86 is just becoming more synonymous with the 64 bit variant, the 32 bit and 16 bit modes are increasingly irrelevant to anyone except boot ROM authors and retro enthusiasts.
  - spijdar 6y ago
    As mentioned above by someone else, what they mean by "x86” is something of a hybrid. The kernel/ring 0 code is certainly 64 bit, and I suspect they may be using 64 bit long mode everywhere, but they're making special accomodations to the many VMS programs that assume 32 bit pointers. This isn't relevant just to VAX code -- because previous versions of VMS made these same accomodations, some programs simply never changed, up to Itanium, despite both alpha and Itanium being 64 bit (and only 64 bit, alpha didn't and I don't think Itanium had "true" 32 bit modes) So "x86” is really referring more to the platform than the specific CPU or mode here, since it'll be a pretty seamless mixture of both.
  - selfhoster11 6y ago
    I have never seen anyone refer to x86 as a synonym for the 64-bit ISA. In the Linux world, it's amd64, in the Windows world it's x64/64-bit, and sometimes in both of those worlds, x86_86. I don't think this loss of distinction is occurring at all.
skissane 6y ago
What they did is more complex than that – the OS is 64-bit, but a lot of legacy apps use 32-bit pointers. All code runs in long mode, but to support those legacy apps, they put code and static data in first 4GB of the address space. 64-bit-clean applications can allocate data above the 4GB mark. 32-bit applications actually run in 64-bit mode, but they assume the top 32-bits of pointers have a fixed value, which means they can safely stash the pointer into a 4 byte memory area. The other thing they do, is put code in the full 64-bit address space, but then have the linker generate trampolines in first 32-bits which jump to the actual function location so 32-bit function pointers can be used for code living outside the 32-bit address space. I believe VMS on Alpha and Itanium did similar things. Applications on VAX assumed 32-bit addresses. Even though Alpha was a 64-bit architecture, to make it easy to port apps from VAX, they had applications mostly use 32-bit pointers (which are really 64-bit pointers with half of their value fixed), if you need more memory, you have to change your application to call some new APIs which return arbitrary 64-bit pointers. And then the same setup was maintained when they ported to Itanium, and now x86-64. Actually IBM z/OS does something similar. IBM mainframes originally used 24-bit addressing, in the early 1980s they moved to 31-bit addressing (not 32-bit, the MSB was used as a flag bit), then around 2000 they moved to 64-bit. However, even in a 64-bit process, they still have the rule that all code has to be in the first 2GB of memory, to simplify interoperation between 31-bit and 64-bit code. But even though all code pointers must be safely expressible in 31-bits, 64-bit applications can use the full 64-bit address space for data.
- andrewf 6y ago
  Sounds a lot like Linux's X32 ABI, but motivated by compatibility rather than memory bloat - https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI
  - skissane 6y ago
    Not quite the same thing. In x32, processes use 32-bit pointers, and can't use 64-bit addressing. An x32 application can't allocate a 8GB memory buffer. Unlike x32, 64-bit VMS lets you mix 32-bit-compatible and 64-bit addressing in the same process. VMS has two sets of memory allocation routines – _malloc32 and _malloc64 – you call the former to get 32-bit compatible pointers, the later gives you the full power of 64-bit addressing. Your app could be a mix of legacy code (which only supports 32-bit) and 64-bit code running in the same process. You want an 8GB memory buffer, _malloc64 will give you one (assuming there is available system resources, of course).

They didn't. It's x86_64 if you look at the startup screen.

Only half joking - "x86" refers to 32 bit, and: "Since the stack and static data on x86 is still allocated in 32-bit address space, a 32-bit pointer is sufficient to point to them." It seems they're still expecting a lot of VAX users to migrate.

fredoralive 6y ago
If x86 refers to 32 bit, what family do the 8086/88/186/286 belong to? 8080_16? :-) I do suspect as time goes by x86 is just becoming more synonymous with the 64 bit variant, the 32 bit and 16 bit modes are increasingly irrelevant to anyone except boot ROM authors and retro enthusiasts.
- spijdar 6y ago
  As mentioned above by someone else, what they mean by "x86” is something of a hybrid. The kernel/ring 0 code is certainly 64 bit, and I suspect they may be using 64 bit long mode everywhere, but they're making special accomodations to the many VMS programs that assume 32 bit pointers. This isn't relevant just to VAX code -- because previous versions of VMS made these same accomodations, some programs simply never changed, up to Itanium, despite both alpha and Itanium being 64 bit (and only 64 bit, alpha didn't and I don't think Itanium had "true" 32 bit modes) So "x86” is really referring more to the platform than the specific CPU or mode here, since it'll be a pretty seamless mixture of both.
- selfhoster11 6y ago
  I have never seen anyone refer to x86 as a synonym for the 64-bit ISA. In the Linux world, it's amd64, in the Windows world it's x64/64-bit, and sometimes in both of those worlds, x86_86. I don't think this loss of distinction is occurring at all.

skissane 6y ago

What they did is more complex than that – the OS is 64-bit, but a lot of legacy apps use 32-bit pointers. All code runs in long mode, but to support those legacy apps, they put code and static data in first 4GB of the address space. 64-bit-clean applications can allocate data above the 4GB mark. 32-bit applications actually run in 64-bit mode, but they assume the top 32-bits of pointers have a fixed value, which means they can safely stash the pointer into a 4 byte memory area. The other thing they do, is put code in the full 64-bit address space, but then have the linker generate trampolines in first 32-bits which jump to the actual function location so 32-bit function pointers can be used for code living outside the 32-bit address space. I believe VMS on Alpha and Itanium did similar things. Applications on VAX assumed 32-bit addresses. Even though Alpha was a 64-bit architecture, to make it easy to port apps from VAX, they had applications mostly use 32-bit pointers (which are really 64-bit pointers with half of their value fixed), if you need more memory, you have to change your application to call some new APIs which return arbitrary 64-bit pointers. And then the same setup was maintained when they ported to Itanium, and now x86-64. Actually IBM z/OS does something similar. IBM mainframes originally used 24-bit addressing, in the early 1980s they moved to 31-bit addressing (not 32-bit, the MSB was used as a flag bit), then around 2000 they moved to 64-bit. However, even in a 64-bit process, they still have the rule that all code has to be in the first 2GB of memory, to simplify interoperation between 31-bit and 64-bit code. But even though all code pointers must be safely expressible in 31-bits, 64-bit applications can use the full 64-bit address space for data.

andrewf 6y ago
Sounds a lot like Linux's X32 ABI, but motivated by compatibility rather than memory bloat - https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI
- skissane 6y ago
  Not quite the same thing. In x32, processes use 32-bit pointers, and can't use 64-bit addressing. An x32 application can't allocate a 8GB memory buffer. Unlike x32, 64-bit VMS lets you mix 32-bit-compatible and 64-bit addressing in the same process. VMS has two sets of memory allocation routines – _malloc32 and _malloc64 – you call the former to get 32-bit compatible pointers, the later gives you the full power of 64-bit addressing. Your app could be a mix of legacy code (which only supports 32-bit) and 64-bit code running in the same process. You want an 8GB memory buffer, _malloc64 will give you one (assuming there is available system resources, of course).