[Info-vax] VAX Macro to C conversion

[Stephen Hoffman]

On 2019-06-24 23:43:45 +0000, Andrew Shaw said:

> ...This is also true and for this I am going to have to do some deeper 
> analysis of the code (as has been pointed out by others in here) in 
> order to understand the subtleties of what is going on - hopefully get 
> an understanding of why it was written in MACRO in the first place. Our 
> system is a curious mix of languages - MACRO-32, C, FORTRAN and RATFOR 
> forms the bulk of the system code...

The use of RATFOR here implies this is an older code-base and/or 
long-established developers, but that combination of languages is 
otherwise not particularly unusual.

It's fairly common to find that much of the existing Macro32 code can 
be replaced with rather less C or C++ code, and/or by making calls to 
now-available system service calls or features.  Or a combination.

There's a lot of Macro32 around that largely exists for historical 
reasons and organizational inertia.  "It works" is a strong contributor 
toward "doing nothing".

More than a little of the Macro32 was implemented as workarounds for 
features or APIs that were then-missing, or for APIs that were not 
easily callable.

Where folks get in trouble with Macro32 is when Macro32 was used for 
the last few crumbs of system performance and/or of memory usage.  Or 
when the developers were too clever. Or a combination.

Whether separately or as a prolog to the source code conversions, I'd 
look at adding instrumentation and debugging into the app, and at 
enabling and cranking up the now-available compiler diagnostics.  If 
you've VAX C code lurking, switch that all over to C99.

Starting a source code conversion with latent bugs and/or insufficient 
test coverage and/or poor telemetry and/or little or no documentation 
(q.v. doxygen) is not fun.  (n.b. I'm not aware of a doxygen port for 
OpenVMS, but it does exist for most other platforms.)

-- 
Pure Personal Opinion | HoffmanLabs LLC