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

[Craig A. Berry]

On 6/10/19 8:54 AM, John Reagan wrote:
> 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.

Tom Wade's VMSARG package can smooth the way a bit here:

<http://www.tomwade.eu/software/vmsarg.html>

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

Thanks for all the explanations and for sharing what you can. A lot of
things seem more tangled up with HPE-owned dependencies than I realized,
even when not using the GEM-compatible front end.

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

It depends.  I guess if someone got an Ada compiler working, they'd
prefer to use their existing build procedures.