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

[Stephen Hoffman]

On 2021-05-29 17:58:00 +0000, John Dallman said:

> Out of curiosity, I took a look at the documentation for the MACRO-32 
> compilers for Alpah and Itanium, and started reading the VAX MACRO 
> instruction set manual.
> 
> I now understand the 32/64-bit issues with VMS a bit better, but I'm 
> curious as to how much of the OS is still written in MACRO-32.

>From the master pack line count I ran ~25 years ago, it was roughly 
thirds between C, Bliss, and Macro32, with then-far-smaller chunks of 
"other" code around.

This is OpenVMS itself. Not the OpenVMS builds, not the OpenVMS tests, 
and definitely not the layered products.

Somewhat more than 64,000 modules in the 64-bit source pool back then, 
and ~330 facilities (groups of modules), IIRC.

New work then was to be written in C per development policies and this 
absent other specific requirements, with updates and enhancements made 
to existing Bliss and Macro32 code and with few new modules.

That was not all that long after C acquired "system programming 
language" status on OpenVMS, too.

> Obviously, this begs the problem of defining the OS, as separate from 
> its utility programs. Let's say "The stuff that's running once the OS 
> has booted and is ready to run applications, plus the programs that 
> needed to run to get it there."

Chunks of OpenVMS user-land code are written in Macro32, and a whole 
lot of kernel code is written in C, so I'm not sure where you're headed 
with your comments about Macro32.

Linux splits up userland and kernel. OpenVMS doesn't.

There are discussions of products produced paralleling their producing 
organizations to be had here too, of course. But I digress.

Some few parts of the kernel do tend to be written in the 
platform-native assembler; in Macro64 on Alpha, and IAS on Itanium, and 
as-yet-unspecified AT&T and/or Intel syntax assembler on x86-64.

The mixture of the languages involved in the rest of the kernel and in 
userland matter rather less, once the compilers are available.

Yes, C, Bliss, and Macro32 each have their issues, and there are 
alternatives and debates to be had there.

Would VSI like to have everything all written in one language? Sure. 
Fewer compilers to drag around. Fewer languages to learn. Easier 
tooling.

But that existing source code is written and ~working, which counts for 
a whole lot in these discussions.

As for the 32- and 64-bit virtual memory design, the 64-bit porting 
manual—which was later rolled into the Programming Concepts manual—was 
a starting point. But that documentation has its gaps.



-- 
Pure Personal Opinion | HoffmanLabs LLC