[Info-vax] 64-bit (was Re: New CEO of VMS Software)

[Stephen Hoffman]

On 2024-01-09 21:35:00 +0000, John Dallman said:

> In article <unkd47$25cg2$1 at dont-email.me>, arne at vajhoej.dk (Arne Vajhøj) wrote:
> 
>> I suspect that all direct calls to LIB$ and SYS$ no matter if it is 
>> Macro-32 or Fortran or C would have to be manually edited to use new 64 
>> bit capable version, but that the various language RTL could switch to 
>> 64 bit capable versions transparently.
> 
> With a sufficiently regular naming scheme, a compiler could make 
> substitutions, but I don't know if the current scheme will cope.

Cope nope. Best reasonably achievable is probably a lint-like tool 
that'll scan for and point to problem areas.

Areas of "fun" will be itemlists, quota lists, and specific itemcodes 
and APIs and app-level code that will probably need to be extended or 
replaced such as UAI$_PWD.

Itemlists are great, right up until you hit the limit. And two passes 
through an itemlist (first for sizing, second for buffers) is less than 
optimal. (I've worked with message-passing APIs that are far cleaner; 
that have less code cruft, and that hide the remapping involved.

OpenVMS is reminiscent of PDP-11 RSX-11M these days, in terms of all 
the "fun" involved in keeping the 32-bit source code and 32-bit 
binaries working.

And if the results of the 64-bit rework are centrally focused on source 
code compatibility with the existing 32-/64-bit APIs and not with 
having a flat 64-bit address space with 64-bit calls throughout, well, 
why bother? Keep that stuff in the current 32-/64-bit world.



-- 
Pure Personal Opinion | HoffmanLabs LLC