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

Bob Gezelter gezelter at rlgsc.com
Mon Jun 10 15:43:46 EDT 2019


On Monday, June 10, 2019 at 1:54:06 PM UTC-4, Simon Clubley wrote:
> On 2019-06-10, John Reagan <xyzzy1959 at gmail.com> 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 ?
> 
> 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.
> 
> 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.
> 
> 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

Simon,

There is a difference between "needed" and "constantly used".

There are some elements which can only be determined from a compiler listing. Actual, debugger-usable line numbers are one. The debugger screen will show the local module line numbers, but there is only so much screen real estate available. Often, I have multiple listings open at the same time on a nearby table.

The same can be said about assembler listings of compiled code. Sometimes, I have had to look at compiled code to see why something is behaving in an unexpected fashion. Daily? No. But the capability is needed, preferably with a degree of symbolization.

- Bob Gezelter, http://www.rlgsc.com



More information about the Info-vax mailing list