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

[John Reagan]

On Sunday, June 9, 2019 at 10:42:26 PM UTC-4, Craig A. Berry wrote:
> 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?
> 

This discussion is blurring some edges between:

1) Code that I think the clang (or LLVM) project will accept into the code pool
2) Code that VSI writes that I think we should share
3) Code that VSI writes that really isn't interesting without HPE-owned code
4) And just HPE-owned code

For the things you mentioned:

- Turning a DCL command line into internal clang settings and flags

That is just a lesson in CLI$PRESENT/CLI$GET_VALUE.  And we use a GEM interface on Itanium C++ so to increase the odds of getting the same command line processed, we'll probably use that same GEM code.  We're currently leaning to writing a separate piece of code that turns the DCL command line into the equivalent of clang's "foreign command" command line and then either chaining or passing it in.  We'll probably have to add some real -xVMS commands to the clang driver for somethings.  clang's driver is structured nicely for such things and has good documentation already.

- VMS listings

You can guess where I'm going...  All of the existing frontends call into a GEM package to create the listing.  That package collects all the diag messages, macro expansions, etc. and creates the .LIS file and optionally the .DIA file.  We'll have to capture the generated code from LLVM in some scheme (I have an idea) but I expect to simply leverage the same GEM routines in clang.  

I expect that none of these edits will be acceptable to push into the clang repo.  And without being able to share the contents of the GEM_CP package, showing the calls to GEM_CP and the return values (notably the setting of GEM_QUAL_Where of either Local, Global, Defaulted) seems mostly pointless.

- CRTL prefix table/Math RTL prefix table

Interesting only to the CRTL and the frontend.  The table that maps "sin" to MATH$SIN_S is buried in LLVM.
  
- LLVM out of the box

It is quite possible that only SOME of our changes will be acceptable to the LLVM project and that you'd need our additional changes as well.  I think we need to share these in some fashion so people can build their own LLVM backend on OpenVMS x86.  Of course, since it is written in C++, you'll need a C++ compiler and we're back to where do you get that from.  Want to bootstrap it from a Linux machine (which is what we're doing) or use our version with all the edits.  It really depends on the business/license model that will be used.  I'm not part of that discussion.  All I can do is call SYS$LOOKUP_LICENSE and look at the result (and when you can build your own, you can skip that call of course)

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

A compiler port to OpenVMS doesn't need a DCL command line or a "traditional" listing file.  Perl and Python for example.  Are they not "friendly" enough?  Would somebody turn down a port of Rust if it didn't have a command line or listing file?

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