[Info-vax] C99 stuff (Re: The Road to V9.0)

[Craig A. Berry]

On 6/9/19 7:09 PM, John Reagan wrote:
> On Sunday, June 9, 2019 at 4:59:50 PM UTC-4, Craig A. Berry wrote:
>> On 6/9/19 10:30 AM, John Reagan wrote:
>>
>>> You won't need any of our changes to clang/clang++ if you are just
>>> interested in porting over open source code. No open source code has
>>> OpenVMS'isms buried in it. However, if you want RTL name prefixing,
>>> etc., you'll need our edits. Since we will be providing a full
>>> clang/clang++, getting it from VSI will be the easy way. Nobody here  > wanting to hack new stuff into clang?
>>
>> I wouldn't think so, but people might want to do all the same things for
>> other languages that VSI doesn't plan to provide.  Let's say for the
>> sake of argument the powers that be command you to produce a
>> VMS-friendly Objective C compiler.  Are you going to forget everything
>> you did to bring up clang/clang++ and never look at the code you've
>> already written?
>>
> 
> LLVM out of the box needs a little help for VMS (adding an arg-count
> for example), but clang out of the box would probably work just fine on
> OpenVMS if you use "-c" to keep the driver from trying to invoke the
> linker, etc. And you won't get prefixing. There is nothing we'll add to
> clang that would be of interest to somebody porting swift for example.

No VMS-style command parsing?  No VMS-style compiler listings?  And why
wouldn't people want to see how you did the symbol prefixing and maybe
even pragmas and builtins?

>> Now turn it around (since you're unlikely to ever have that mandate) and
>> say someone else wants to do it.  Wouldn't they benefit from being able
>> to just take what you've done and adapt it?  Even things that you may be
>> pushing back into LLVM (generating debug code that works for the OpenVMS
>> debugger?), would be a lot easier to do from a working example.  Sure,
>> people can probably figure it all out for themselves if they devote the
>> resources to doing so, but wouldn't it be to everyone's advantage if
>> they didn't have to?

> The VMS debugger will be able to swallow the DWARF4 (and eventually
> the DWARF5) from LLVM.  If not, the debugger is broken.  I expect
> that you can take the LLVM with OpenVMS additions and hook up any
> frontend to it that you want.

OK, good, as far as the debugger input.  But I did say a "VMS-friendly"
compiler, by which I mean one that looks and acts like a native compiler
wherever it came from.  Maybe for you the command parsing and other
peripheral components are the "easy" part of making a compiler (no bit
twiddling required), but that doesn't mean reference examples would not
be a big leg up for folks who have a compiler but no familiarity with VMS.

Rob's claim was that none of the code VSI produces would be worth
anything as open source because you can't get the whole enchilada as
open source.  I guess this is not surprising given the history of
OpenVMS Engineering in DEC/Compaq/HP/HPE with open source, but it is not
how successful companies (Microsoft, for example) deal with open source
these days.  Of course Windows, SQL Server, and other key bits are not
open source, but there are tons of other pieces, from .Net to assorted
compilers and tools, that are open source, so people can not only use
them for free, but can adapt them and make other new things based on them.

And every other platform in widespread use does something similar
because it's considered table stakes for attracting developers to the
platform.  If VSI ever wants to attract anyone but stubborn old people
as developers . . . .