[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-27 13:20:28 +0000, John Reagan said:

> On Monday, July 27, 2020 at 8:47:36 AM UTC-4, Simon Clubley wrote:
>> On 2020-07-24, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>>> 
>>> Tried building a 64-bit app without having to contend with 32-bit 
>>> giblets including the 32-bit APIs, the 64-bit APIs, and the either-bit 
>>> APIs, and the switch qualifiers to get everything to 64-bit, and the  
>>> stuff that isn't yet 64-bit?
>> 
>> John, this is why the current setup is not a flat 64-bit implementation 
>> but is a hybrid of 32-bit and 64-bit modes.
>> 
>> The current 64-bit memory model on VMS reminds me somewhat of the old 
>> segmented memory models that used to exist under MS-DOS before the flat 
>> 32-bit address space came into use on the x86.
> 
> As I said, it is a flat 64-bit address space. There is no "mode".  We 
> just decide to load the stack, the static data, and code into addresses 
> that can fit in 32-bits because of the history of descriptors and 
> itemlists with 32-bit pointers in them.  It is part of the "recompile 
> and go" we promised back on the VAX days.  We require that anybody 
> wanting to use memory that needs a 64-bit pointer to modify their 
> compile command or source files. However, you can't move the stack or 
> static data.  You just get to heap allocate or mapsection into those 
> memory ranges.  And as I mentioned, for x86, we move your code there to 
> leave more 32-bit room for stack and 32-bit addressable heap.

I'm happy to be corrected here, but AFAIK there are no 64-bit apps on 
OpenVMS. None. There are 32-bit (~30-bit) apps with 64-bit (50-bit?) 
extended, or segmented, or, sure, maybe flat, addressing available. But 
there are no 64-bit apps.

And yes, this current design is a central feature of the compatibility 
costs and trade-offs that were and are and will be inherent in the 
"compile and go" goals.

This current design is certainly acceptable and workable for existing 
apps that need bigger wads of data, too.  Which was why it was designed 
and quite reasonably chosen.

The 32-bit API limits and the 32-bit compiler limits are among the 
impediment on the path to 64-bit apps.  Linker work or linker testing, 
as that's involved with building 64-bit apps.

Getting a flat address space and getting rid of the mumble() and 
mumble64() and 64-bit objects is no small development project, and 
that's past the remediations for the forever-32-bit-app dependencies 
that lurk.

As I've mentioned before, around other OpenVMS features...

...Go try using 64-bit addressing, past P2- or S2-space buffers. Then 
tell me how easy it was to use the features, particularly as compared 
with a flat 64-bit environment with flat 64-bit APIs and 64-bit calls.

...There are 32-bit wrinkles awaiting in a fair pile of the app source 
code. In C, some of the featured contestants here can include 
ptrdiff_t, time_t, off_t/loff_t/off64_t, etc. Other languages will have 
other limits. RMS and XQP and LBNs and VBNs. too.

...itemlists were a good example of API designs in years past, and 
itemlists now look rather more like piles of ugly glue code, and 
increasingly glue code that's getting in the way with entrenched buffer 
size limits. Objects help opacity.

>>> Every time I've tried creating a 64-bit app, I get a sad and revert to  
>>> 32-bit with hunks of data up in P2 and/or S2.  At one point—haven't 
>>> verified this limit lately—code wasn't permitted in some of the 
>>> segments.
>> 
>> I hope you are not having to copy the same data between P2 and P0 to use it.

Copying data can be fairly commonly encountered, though I try to design 
to avoid that.

For these cases, I've sometimes used section mapping and addressing 
windows as was referenced earlier, which brings app designs all the way 
back to Apple II segmented addressing, and earlier.

The overhead of (re)mapping has to be profiled against the overhead of 
the copy.

Data and buffer copies lurking in complex apps can and seemingly do 
breed in the absence of active suppression efforts.

The effects of data copies on performance here are analogous to the 
effects of buffer copies in device drivers.

> Can't speak directly for Steve, but copying back into 32-bit 
> addressable memory ranges exists at various places in the system.

Marketing can certainly declare OpenVMS to be 64-bit and not segmented 
and the case could be made, but I'd be surprised if most app developers 
would agree it's feasible to create 64-bit apps.

Most of the OpenVMS apps and the present scale of server hardware 
running OpenVMS is really not that much past 32-bit configurations; 
32-bit apps, with addressing extensions for data.

OpenVMS can be a very good choice for existing apps, and for apps 
receiving maintenance and incremental updates.

For wholly new apps and for substantial app overhauls and for larger 
volumes of data, OpenVMS suitability gets a little more murky.





-- 
Pure Personal Opinion | HoffmanLabs LLC