[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-23 17:38:33 +0000, Simon Clubley said:

> On 2020-07-23, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> On 2020-07-22 16:40:48 +0000, Robert A. Brooks said:
>> 
>>> Paul Anderson and I have largely scrubbed any VAX-specific stuff from 
>>> the build command procedures and MMS description files, and in some 
>>> cases from the source, in order to make things more readable.
>> 
>> Ditching 32-bit source code and 32-bit conditionals can make the source 
>> code much simpler, particularly when the source code is working with 
>> 64-bit values.
>> 
>> Lots of limitations in the older 32-bit APIs, too. Particularly as the 
>> same source code starts to adopt 64-bit operations and addressing.
>> 
>> Going to flat 64-bit addressing would simplify this further, though a 
>> decade-long migration to flat 64-bit addressing would be exceptionally 
>> fast.
>> 
> 
> If flat 64-bit addressing is ever going to happen, it's going to have 
> to come with some kind of a 32-bit addressing mode for existing code.

The not-flat 32-/64-bit compatible address space already exists. It's 
really a quite impressive and functional design, within its fundamental 
keep-32-bit-code-working constraint.

> There's just too much going on at an unabstracted low level in VMS code 
> for flat 64-bit addressing to be viable by itself without any other 
> addressing modes.

What has happened else-platform is a flat 64-bit address space with 
64-bit apps that ran in parallel with the 32-bit space and 32-bit apps 
on the same system, until the 32-bit space and 32-bit app APIs were 
eventually discontinued.

This'd take at least a decade as mentioned (and that'd be 
"exceptionally fast", too) and quite possibly twenty years or more 
within an environment that tends to upgrade systems and upgrade apps 
with the leisure that is common with many OpenVMS installations.

But then, I don't expect work toward a flat 64-bit address space and 
related work to happen at VSI. That'll be viewed as too long term an 
investment, and as too disruptive. And deprecating the limited or 
fundamentally-broken APIs seemingly too difficult.

Using the current 64-bit addressing interfaces on OpenVMS is an 
unmitigated disaster, but then I'm feeling polite today. This having 
just tangled with the current 32-/64-bit hybrid addressing design yet 
again.

For those accustomed to flat 64-bit addressing, the current 32-/64-bit 
hybrid design and the current mishmash of 32- and 64- and 
dual-compatible APIs is increasingly reminiscent of contending with TKB 
and RSX-11M, for those that remember that.

BASIC would probably be one of the better targets here for flat 64-bit 
work too, in addition to object-oriented update work that's been 
discussed before in threads other. C and some other compilers already 
have 64-bit support and with API constraints, of course.

> You would also need some way of supporting the current 32-bit/64-bit 
> mixed addressing unless you outright discontinue such support.

The current 32-/64-bit hybrid design isn't going to improve 
significantly enough to matter here, no matter how much work goes into 
the current hybrid design.

> P1 space would also be right in the way of a flat 64-bit addressing 
> mode so all the code which uses P1 space would have to be rewritten to 
> support flat 64-bit addresses because P1 space would have to be moved 
> well out of the way.

P0 and P1 space and S0 and S1 space are for VAX compatibility within 
apps and app source code.


-- 
Pure Personal Opinion | HoffmanLabs LLC