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

[John Reagan]

On Monday, June 10, 2019 at 1:54:06 PM UTC-4, Simon Clubley wrote:
> On 2019-06-10, John Reagan <> wrote:
> >
> > 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?
> >
> 
> There may be some dogma going on here along the lines of "that's the
> way it has always been done so that's how it should be done on x86-64 VMS".
> 
> Such dogma doesn't address the question of whether the old way is still
> the best way.
> 
> 1) Compiler listings:
> 
> How many of you actually _use_ the listings and how do you use them ?
> 

Well, *WE* still use full listings all the time.  Each build of the system, we end up with a complete set of listing files and map files.  It allows us to go "back in time" and see exactly what the compiler saw and exactly what the compiler produced.  And right now, we rely heavily on the source listings (our cross-compilers make them) and the ANALYZE/OBJECT/DISA output as a pseudo machine code listing.  The /DISA output has line # info (it knows how to read the DWARF line tables) but doesn't have much else in terms of symbolization.  It also doesn't print out any of the static initialization directives since it is all just random bytes by the time the .OBJ is written out.

> I have not generated compiler listings in a long time. There is one
> form of listing I do use (but not on VMS), and that's the output from
> objdump and friends when I am looking at the generated code for an
> embedded system image to see if the compiler or linker has done
> something unexpected.
> 
> Even in that case, that's a listing of the final linked image and
> nothing to do with the compiler as such.
> 
> People on other systems seem to manage just fine without listings
> so why are they still needed in 2019 on VMS ?
> 
> 2) DCL or Unix style CLI:
> 
> With clang (and any other frontends such as the Fortran one), there is
> an argument for supporting the traditional DCL qualifiers via a mapping
> module to the underlying Unix style command line so that normal compiles
> continue to work as expected.
> 
> However, I don't see why the vast range of clang command line options
> (see https://clang.llvm.org/docs/ClangCommandLineReference.html for
> full details) should need to be mapped to a DCL qualifier for each
> and every clang option.
> 

We aren't going to do that (sorry if I implied that).  We'll figure the mapping from the current DCL qualifiers to clang command line options (possibly inventing a few new ones).  We might add a few (and I mean FEW) new DCL options to control certain clang behaviors (like adding new keywords to /STANDARD or adding new keywords to /ARCH or /OPT=TUNE=)

> You are going to have to learn that new DCL qualifier name anyway from
> some mapping table in the documentation so you may as well just use
> the native clang option name via the Unix style command line and have
> done with it.
> 

To aid with that, I think we'll end up with an option of to print out the equivalent clang command option for a given DCL command.  

> That way, you get the best of both worlds. You get a DCL style command
> that you can use with your existing build environments and if you
> really need to dig into the full range of options that clang offers,
> you can do it via the normal clang command line.
> 
> Simon.
> 
> -- 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world