[Info-vax] VAX Macro to C conversion

[Stephen Hoffman]

On 2019-07-12 16:36:29 +0000, Aron Insinga said:

> A single VAX instruction can be compiled into a _sequence_ of 
> instructions for another machine.  A single VAX MACRO ADDL3 instruction 
> might become 4 instructions for a RISC machine: load, load, add, and 
> store.  Of course the sequence gets more complicated depending on the 
> instruction, the addressing modes, etc.

You are quite correct.

But...

Ponder in what universe—outside of some marketeer's fever dreams around 
some hypothetical instructions-per-cycle marketing campaign, and 
marketeering for which there is some precedent I might add—does an 
instruction count centrally matter?

And x86-64 instructions themselves get translated into micro-ops, so 
even counting macro-instructions is a murky comparison.

Of Macro32 and C on OpenVMS, C is going to be the preferred approach 
for new work and for substantial overhauls.  That is, of Macro32 and C. 
 Not of Macro32 and whatever your preferred languages here might be.  
Of Macro32. And C.

Of Macro32 source code and C source code, Macro32 requires more source 
code statements—and whether statements represent VAX hardware 
instructions or are compiled into x86-64 instructions, or 
otherwise—than does C source code. And not by a little.

*This* is the problem leading toward migrating from assembler semantics 
to languages with higher-level abstractions.

*This* is what folks are looking to address.

Pragmatically, having less source code—and less glue code—means fewer 
source code bugs.  Not comparisons of the numbers of hardware 
instructions are produced by a compiler, and that comparison only after 
we've had a look at the performance and the efficacy of the compiler 
optimizer.  Or in concert with the linker optimizer, though that 
tooling is not (yet?) something typically found on OpenVMS.  (Post-link 
optimizations were also intended to factor into improving the 
performance of Itanium executables, but that capability was never made 
available on OpenVMS.)

In different realities, another language is often (usually?) more 
appropriate than C.  And in some of those realities, wholesale rewrites 
are even feasible and viable.  But that's not where many of us are 
right now.  Particularly for VSI, as they've seemingly too few folks on 
staff for what they need to do, much less for what they want to do.  
There's always more work than there's available schedule time, which 
means we're always compromising with what can get shipped and when.

Most of us working with OpenVMS are in a reality where use of C remains 
endemic on OpenVMS, and where something approaching half of all the 
source code present in OpenVMS is written in C, and yes, where C is 
problematic and for various reasons.  That means VSI and many of us are 
using C and maybe C++.  And it means we'll be looking toward using 
C17/C18/C11 and features well beyond the not-really-C99 available at 
present on on OpenVMS. And we will (hopefully) see the integration of 
the address sanitizer, safe-stack, and/or various other LLVM-based 
tools including fuzzing tools, as well as the advent of mechanisms 
that'll help guide C developers toward better coding practices and 
better APIs.  That'll all be incremental.  And the capabilities of the 
newer compilers (e.g. -Wall -Wextra -pedantic) including these and 
other newer tools are akin to but are generally past what tools such as 
/WARN=ENABLE=QUESTCODE currently provides on OpenVMS.  And it'll mean 
most of us will be reading the new C docs and the new LLVM docs, and 
mapping all that into our own development efforts.

Adding new source code in some new language into a project means adding 
yet another language into OpenVMS itself, and that then means getting 
that language over onto and maintaining it on OpenVMS or maintaining it 
in our own environments, and it means keeping enough of the staff 
familiar with that language to maintain and update both the language 
and the apps written in that language.  Some of the 
less-common-language source code projects that have been added into 
OpenVMS over the years have become problematic.  There are various 
examples here, not the least of which are Macro32 and Bliss.   Various 
of those have necessarily been rewritten into some other language.  
Unsurprisingly, typically into C.  Adding new languages to an existing 
environment is not to be taken lightly.  Well, not unless you already 
have a cache of developers familiar with that tooling, and where you 
have that tooling available and current and maintained.

In five or ten years and after VSI has a stable and speedy version of 
OpenVMS available on x86-64 available, maybe that new OpenVMS work 
might start to be written be Rust, Go, or some other contemporaneous 
alternative, with the selection depending whether this is lower-level 
and system-level work, or if this is higher-level app work, and various 
other factors.  And VSI is probably also going to want to control the 
compilers and tools used, lest they end up beholden to an external 
entity and an external dependency.

For the foreseeable future with OpenVMS, we're going to see continued 
use of the Macro32 compiler and the Bliss compiler, and some of the 
existing Macro32 and Bliss incrementally rewritten in C when heavy 
modifications are required, and new work in C.  Preferably into newer 
C, with newer compilers, and current clang diagnostics.  Again, this 
isn't the reality that many (most?) of us might want, but no matter 
where we go, there we are.

This whole mess won't resolve itself in the next decade, much less in 
this current one.  Best case, the existing tooling gets far better and 
more abstracted, and newer programming languages become available and 
increasingly and more widely accepted on OpenVMS. And maybe we're 
increasingly dealing with nicer processor environments, including Arm 
and RISC V designs.  Worst case, too many of us are still debugging 
(compiled) VAX assembler source code, and chasing K&R C code stuck at 
VAX C, or ANSI/ISO C with laissez faire compilation settings, and 
dragging old FORTRAN code forward to Fortran, and tussling with UTF-8 
in an ASCII / DEC MCS world, etc.  But we can hope...

Additional reading:
https://clang.llvm.org/docs/AddressSanitizer.html
https://www.llvm.org/docs/LinkTimeOptimization.html
http://clang.llvm.org/docs/SafeStack.html
https://clang.llvm.org/extra/clang-tidy/ (a Clang-based lint tool)
https://www.youtube.com/watch?v=xnEAPBpSqLQ


-- 
Pure Personal Opinion | HoffmanLabs LLC