[Info-vax] VAX Macro to C conversion

[Andrew Shaw]

On Tuesday, June 25, 2019 at 9:59:37 AM UTC+10, Stephen Hoffman wrote:
> 
> 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.
This is definitely an older code-base rather than established devs. Probably been around since approx 1980 - ish. (Not at work now so can't confirm, but that's about right). All the original Devs are long gone. Current "veteran" has been on it for just shy of 20 years. Rest of us are 2-3 years or less here - I'm probably the longest serving VMS guy here now, most of the others are newcomers to this world.



> 
> 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.

This is a really good point and I like it. My gut tells me that a lot of our Macro will be doing just that. I suspect that a lot can be replaced with a fairly simple high level call nowadays that today's compilers can then optimise to their hearts content and we may wind up with code more efficient and quicker than the Macro. But at this stage that is purely guesswork and more digging is needed from me to either prove or disprove that.

> 
> 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".

That's strong here. We know it works, we don't need to touch it, we don't want to mess with it - leave it alone.

> 
> 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.

Yup, see above comments. I suspect we have a fair bit of this.

> 
> 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.

I'm not going to say we don't have this, because I don't know yet.

> 
> 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.

Another excellent suggestion and one my colleague and I arrived at separately in a conversation we had only this morning. I think there is some preliminary analysis that we can knock up which will help put a shape and size around this "problem". There is a chance some/a lot of our Macro code is now superceded and not used anymore and in that case I am trying to solve a problem I may not actually have. So I really do think trying to dimension it first is smart.

> 
> 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.)
> 

I wasn't aware of doxygen until now. My colleague was and suggested that if push came to shove we could potentially copy the code to a Windows or Linux machine somewhere and run doxygen over it from there. Not sure how feasible that is though - again, a bit more digging needed on my part.