[Info-vax] How much of VMS is still in MACRO-32?

[Stephen Hoffman]

On 2021-05-30 09:00:00 +0000, John Dallman said:

> The reason for distinguishing, now that I've thought about it a bit 
> more, is that the kernel, some device drivers, the loader and so on 
> need to be able to deal with 64-bit addresses, memory above the 4GB 
> line, and so on. That isn't something that MACRO-32 does natively. In 
> contrast, some of the utility programs can probably remain 32-bit 
> forever, so there's less need to revise them.

There's all sorts of design and particularly ugly API shenanigans to 
allow 32-bit apps to work within 64-bit space, and the OpenVMS V7.0 
64-bit design is great at that.

The existing design is great for existing apps and for incremental 
changes to existing apps, but not so great for new work, nor for 
substantial refactoring, nor for incrementally fixing busted APIs.

The Macro32 compilers all use 64-bit addresses internally, with sign 
extension. As do all other apps on the 64-bit platforms.

Within the Macro32 compilers, BASIC, C without the 64-bit knobs 
twiddled in the compiler and in the linker, and other such, the code is 
restricted to accessing S0, S1, P0, and P1 addresses absent "creative" 
coding; the lowest 31 bits and highest 31 bits of 64-bit address space.

(qv: my previous rants on this topic, having experience using flat 
64-bit apps and by-default 64-bit APIs and ABIs else-platform.)

But the kernel is also not source code that would be (or is) written in 
assembler.

With very few exceptions, all new device driver work and kernel work 
has been in C, before Y2K.

See the Step 2 driver manual doc in the 'net archives, from OpenVMS 
Alpha V6.1, etc.

The uproar around migrations from 2GL to 3GL that was raging through 
the 1980s and 1990s died out a while back.


-- 
Pure Personal Opinion | HoffmanLabs LLC