For those of use still smarting from our VAXectomies.
VSI OpenVMS v9.0-G Released (x86 port)
11–20 of 44 posts
Re: VSI OpenVMS v9.0-G Released (x86 port)
#12It's funny how they targeted 32 bit x86 instead of just going straight for 64 bit. I wonder what drove that decision.
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.
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.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#13No download available? I thought it'd be fun to mess around with but maybe it's for paying customers only.
The Community License page has checkboxes for Alpha and Itanium. The box for "x86 (planned)" is not yet enabled: https://vmssoftware.com/community/community-license/ I guess I shouldn't be surprised that this is a VM-only product, but there's something unsatisfying about an O/S that can't boot real hardware.
> but there's something unsatisfying about an O/S that can't boot real hardware
According to their roadmap [0] they are aiming to release support for running on HPE DL380 servers bare metal this year, followed by support for some 2 socket Dell servers next year.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#14Who's using VMS these days? (not a dig, I'm wondering)
VMS is / was popular in the transaction processing industry: financials, lottery, casino, etc. However, most of the folks I know working in that industry moved on to other platforms over a decade ago.
I have an AlphaStation as part of my retro collection. It has OpenVMS on it, but hasn't been booted in a while.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#15Who's using VMS these days? (not a dig, I'm wondering)
A university I worked at migrated from independent VMS systems (student, finance, HR) to an ERP system. To make that implementation easier, they only converted the most recent few years of data.
Last I heard they had some sort of virtual machines emulating Alpha hardware still running those legacy systems.
My current employer (also higher ed.) is hosting somebody's ES40. Some people in higher ed. really, really liked VMS and the Alpha/Itanium platforms.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#16It's funny how they targeted 32 bit x86 instead of just going straight for 64 bit. I wonder what drove that decision.
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.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#17Who's using VMS these days? (not a dig, I'm wondering)
I haven't worked there for a few years, but I'm 99% sure that German stock exchange in Frankfurt (https://www.deutsche-boerse.com/dbg-en) is still operating their clearing operations (central counterparty) and some others on OpenVMS/Itanium servers from HP
Re: VSI OpenVMS v9.0-G Released (x86 port)
#18Earlier quoted context omitted.
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.
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.
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.
Re: VSI OpenVMS v9.0-G Released (x86 port)
#19It's funny how they targeted 32 bit x86 instead of just going straight for 64 bit. I wonder what drove that decision.
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 mean…
Sounds a lot like Linux's X32 ABI, but motivated by compatibility rather than memory bloat - https://en.wikipedia.org/wiki/X32_ABI
Re: VSI OpenVMS v9.0-G Released (x86 port)
#20Earlier quoted context omitted.
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 mean…
Sounds a lot like Linux's X32 ABI, but motivated by compatibility rather than memory bloat - https://en.wikipedia.org/wiki/X32_ABI
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).