[Info-vax] VAX VMS going forward

[Stephen Hoffman]

On 2020-07-30 21:18:29 +0000, Mark Berryman said:

> On 7/30/20 2:39 PM, Stephen Hoffman wrote:
>> On 2020-07-30 20:13:36 +0000, Mark Berryman said:
>> 
>>> In conclusion, while there is certainly still some work to be done, I 
>>> don't think it is that onerous to write a 64-bit app in current VMS.
>> 
>> That's 32-bit/P0 code (technically ~30-bit) with 64-bit/P2 data. Which 
>> wasn't too bad to create, as was mentioned. This if you have all of 
>> your dependencies capable of 64-bit/P2 references.
> 
> Flashback to my RSX days when I could run/write "really big programs" 
> because all of the system libraries were mapped in supervisor space...
> 
> Let's see, 30 bits is 1G, right?  I don't have executables on my 
> systems that are anywhere near that size, but that doesn't include any 
> sharable libraries they may link to.  Where are these loaded in current 
> VMS?  Are they limited to P0 space?  If so, then yes, I can see 
> situations where that could become a limiting factor.

It all has to fit in P0 space; the executable code.

>From dim memory, apps were also long limited to 42(?) shareable images 
due to image header limitations, though that particular limit probably 
disappeared with ELF.

I've become accustoming to not having a big wad of... stuff—P0 and 
particularly P1 space—parked in the lowest-addressed of the application 
address space, and of not having to mix in APIs and dependencies that 
expect and require finding that wad of... stuff.

And accustomed to APIs which aren't nearly as dependent on glue code, 
for that matter.

The OpenVMS 32-bit APIs (P0 and P1 space) and resulting app and 
shareable image dependencies get tedious to work with and to work 
around.

As with DECnet and other longstanding problems, I'll wager that those 
old APIs are not going away until they're solidly deprecated and gone, 
and probably not even then.

And AFAIK, code outside of P0 space isn't yet supported. Executable or 
shareable or otherwise.

Having worked with a platform that deliberately broke addressing and 
APIs hard when making the transition from 32-bit addressing to 64-bit 
addressing, and that forced reworking and rebuilding apps, and that 
then allowed 32-bit and 64-bit apps to operate in parallel in separate 
processes, I find the current OpenVMS hybrid design is... convoluted.  
Even as familiar as it is. The hard migration also allowed developers 
to keep the same API names for the equivalent now-promoted API 
routines, which meant sys$mumble didn't need to have a sys$mumble64, 
which meant half as many routines to memorize, particularly as the goal 
was ditching the old 32-bit environment. The IDE is also good at 
spotting argument mismatches as you edit or as you type the source code 
in, which made the related parts of the source code migration that much 
more obvious.


-- 
Pure Personal Opinion | HoffmanLabs LLC