[Info-vax] C and C++, Macro32 (was: Re: Fortran)

[Stephen Hoffman]

On 2018-12-05 15:18:43 +0000, John Reagan said:

> Not to worry.  Under no circumstances would we add /STANDARD=VAXC to 
> clang. That would be insanity.

The less y'all have or want or need to add to clang C and C++ and the 
less divergent the clang library support for C and C++ is, the better.

Port over the DEC C environment (DEC C, Compaq C, HP C, HPE C, VSI C), 
avoid embedding it any further than necessary, and announce its 
maturity and plans for eventual deprecation.

Allow folks ~five years to migrate their C and C++ to clang and to the 
separate clang C libraries.  Then deprecate the DEC C environment.  In 
another five years, remove DEC C as a product.

Having RMS keywords embedded in C I/O is both handy and utterly 
hideous.  And the "fun" with SSIO and the OpenVMS-isms around file 
handling and I/O continue to cause problems.

I'm of two minds around allowing C to handle OpenVMS file 
specifications in C I/O statements, too.  But it really doesn't do that 
now.  Not very well.  Have a look at basename(3) for an example of that 
omission.

I'd much rather see support for C and C++ blocks, and—with the 
availability of the LLVM port—maybe eventually VSI or third-party ports 
of Objective C, Objective C++, Swift and other LLVM languages.  Beyond 
possibly flang, that is.

Given the compiler sizes and the comparative storage capacities in this 
era, I'd be tempted to roll together all of the major compilers and 
DECset and the ports of git and cmake into a developer installation 
kit, and roll Python 3 into the base distro.  Simplify the OpenVMS 
installation and management processes, and simplify the licensing.  And 
a DVCS means that mixed-architecture clustering isn't nearly as central 
to porting code around, either.  But I digress.  Yeah, this 
radical-tool-decomplexification project prolly won't happen any time 
soon, as there's unfortunately little incentive to simplify.  It's a 
longer-term investment in OpenVMS.  As for pricing, vendor development 
tools are often free, and sometimes quite powerful.  VSI already does 
this in and in couple of different ways, but hasn't aligned and 
integrated these practices with the development tool packaging.

> We're more likely to recode our Macro32 into JavaScript and PHP.

With tools akin to emscripten and binaryen, JavaScript may well be 
easier than might be assumed.  Even for at least some kernel Macro32 
code, thanks to wasmjit.

https://github.com/kripken/emscripten
https://github.com/WebAssembly/binaryen
https://github.com/rianhunter/wasmjit

Yeah.  I'm not serious about this Macro32 part.  But I am serious about 
deprecating the old DEC C and DEC C++ environment and getting everybody 
over to clang.

Though there are some folks thinking about VAX Macro32 source code 
translation: http://xtran-llc.com/vxmlbs.html — there's at least one 
other bunch around, too.

Yeah.  Development tools—well beyond compilers, these days—will be a 
lively discussion.  Port first.  Etc.



-- 
Pure Personal Opinion | HoffmanLabs LLC