[HN Gopher] VSI OpenVMS v9.0-G Released (x86 port)
___________________________________________________________________
VSI OpenVMS v9.0-G Released (x86 port)
Author : todsacerdoti
Score : 33 points
Date : 2021-02-17 17:47 UTC (3 hours ago)
(HTM) web link (vmssoftware.com)
(TXT) w3m dump (vmssoftware.com)
| johnklos wrote:
| It's funny how they targeted 32 bit x86 instead of just going
| straight for 64 bit. I wonder what drove that decision.
| icedchai wrote:
| They didn't. It's x86_64 if you look at the startup screen.
| johnklos wrote:
| 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 wrote:
| 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.
| skissane wrote:
| 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.
| crashdelta wrote:
| Who's using VMS these days? (not a dig, I'm wondering)
| icedchai wrote:
| 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.
| 3nf wrote:
| 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.
| unixhero wrote:
| Oooh
| trynumber9 wrote:
| No download available? I thought it'd be fun to mess around with
| but maybe it's for paying customers only.
| mepian wrote:
| There is the community license program, but I don't think it
| includes the x86 port yet:
| https://vmssoftware.com/community/community-license/
| SloopJon wrote:
| 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.
| spijdar wrote:
| In this space it's not too unusual, really. It's not
| altogether unlike modern AIX or IBM i, which effectively only
| run on virtual machines managed by a hypervisor built into
| the firmware on PowerVM machines. Maybe less satisfying since
| it's less integrated with the hardware, but in a sense the
| paravirtual devices are kind of just another type of
| firmware/driver layer.
|
| I kind of hope more (new) OSes adopt a similar model.
| Developing cool new experimental OSes would be easier if real
| hardware could be "ignored" in favor of just targeting virtio
| interfaces or something, and IMO that's where the most
| interesting OS dev is yet to happen. If you're mostly
| interested in hardware support and raw performance, I think
| Linux has "done it". But there's a lot left to explore, and
| maybe it's best to find a way to get Linux to do the heavy
| lifting.
| skissane wrote:
| > 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.
|
| [0] https://vmssoftware.com/about/roadmap/
| meepmorp wrote:
| For those of use still smarting from our VAXectomies.
___________________________________________________________________
(page generated 2021-02-17 21:00 UTC)