[Info-vax] C and C++ and clanger-free clanging (was: Re: Porting to Linux instead of x86-64 VMS, ...)

[Stephen Hoffman]

On 2019-07-03 20:29:18 +0000, John Reagan said:

> I was talking about the "syntax" clause in the .CLD file.  I'd like 
> /STANDARD=C11 to invoke a different image.  I could make it really 
> twisty and have the legacy VSI C compiler do a LIB$DO_COMMAND of 
> clang-as-a-C11-compiler when /STAND=C11 is set.

I believe you have that somewhat backwards.  Absent /STANDARD=C99 (C90, 
VAXC, etc) or specific request for obsolete tooling, invoke the current 
compiler.  With an explicit /STANDARD=C11, invoke the new compiler.  
/STANDARD=C18, as Clang rolls that out.  Stop preferring sites that 
aren't updating their code for those that are and will; easier mid- and 
longer-term over easier short-term.  Start acting like y'all are 
planning to be around for a few years.

> The problem with that is that clang-as-a-C-compiler will never support 
> lots of pragmas that the legacy C compiler does.  It seems too 
> confusing to magically switch the compiler out from under you with a 
> /STANDARD qualifier option.  I want to make it clear that asking for 
> C11 means a different compiler.  If you want to move into the future 
> (er, past) with C11, it means you have to let go of the legacy tree.  
> Of course, open source software coming to OpenVMS for the first time 
> won't use any of those old DEC features.

I won't suggest enhancing the DCL syntax parsing implementation here.  
But that's clearly what you're tussling with.  That there's no 
alternate syntax selection on keywords.

As for the selection, allow folks that aren't going to update their 
software to SET COMMAND SYS$ETC:LEGACY_CC.CLD at login or at the top of 
the build procedures.

We will already have to modify procedures and sources for the port, so 
make us do implement the compatibility changes for the legacy and the 
unmodified and the buggy code, and leave the rest of us to the current 
tools with our (newer) work.

Certainly cater to the existing source code and to those folks that 
can't or won't update or refactor their source code, but please don't 
do that at the expense of newer work and newer development and newer 
adoption.

Please don't make the defaults for new work worse.

Add the work for the folks that want to keep the outdated and insecure 
and buggy environments.

And as part of this, advertise that you're making these changes to make 
new development easier.  Explain why.  Explain what the benefits are.  
Explain that you're investing in updates—show that you're investing. In 
making OpenVMS better.  More competitive. And part of that work will 
(unfortunately) inherently and occasionally entail making a few and 
very specific changes to existing source code. Document how bugs have 
been and will be found by doing this, too. How the app code becomes 
better and more reliable and more secure.

Asking what customers want?  That's good for incremental stuff.  For 
what can help very specific workloads, too.  For the sorts of major 
improvements and major enhancements that'll pull the customers forward 
in numbers, that's something y'all will have to figure out and build 
and/or port at VSI.

> For the CXX DCL interface to clang++, I don't see us providing an 
> arbitrary /CLANG_OPTIONS="random string".  We'll provide a reasonable 
> mapping for the existing DCL syntax for the "recompile-and-go" crowd.  
> We'll probably add some support for various common hardware flavors 
> with /ARCH.

Is this /ARCH selection going to be related to selecting from the Intel 
settings that show up with the macOS sysctl -a machdep.cpu command?  
Akin to the Alpha AMASK and IMPLVER?  Figuring out which set of 
features is present and/or necessary tends to be a morass, otherwise.

$ sysctl -a machdep.cpu | grep -i features
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR 
PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE 
SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM 
SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 
TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: SMEP ERMS RDWRFSGS TSC_THREAD_OFFSET BMI1 
HLE AVX2 BMI2 INVPCID RTM SMAP RDSEED ADX IPT SGX FPU_CSDS MPX CLFSOPT
machdep.cpu.extfeatures: SYSCALL XD 1GBPAGE EM64T LAHF LZCNT PREFETCHW 
RDTSCP TSCI
$

BTW, I assume something akin to SHOW CPU /FULL will be showing this 
list, or something similar?


> Maybe a few others.  But if you want to specific lots of strange exotic 
> options, use the foreign command form.  That said, if you compile 
> without -fPIC (and perhaps a few other ones), the object probably won't 
> link/execute correctly.  In order to support shareable images, 
> INSTALL/RESIDENT, etc., you must compile with -fPIC.  The DCL interface 
> will set that for you.  We'll provide guidance when the time comes.

Thanks for that info.  I'd tend to expect OpenVMS code to be 
position-independent code (PIC), so not a big surprise there.



-- 
Pure Personal Opinion | HoffmanLabs LLC