[Info-vax] GCC for VMS, was: Re: fortran compiler roadmap?

[John Wallace]

On Apr 18, 4:03 am, "Craig A. Berry" <craigbe... at mac.com.invalid>
wrote:
> In article <kkmqqa$rr... at dont-email.me>,
>  Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> > On 2013-04-17, Stephen Hoffman <seaoh... at hoffmanlabs.invalid> wrote:
>
> > > The last version of gcc I met for VMS was very old.  Specifically went
> > > looking for gcc for inclusion on the last Freeware, too.
>
> > Ada Core Technologies (ACT) maintains a port of gcc for it's VMS Ada
> > customers. The source code was not freely available however the last
> > time I looked (several years ago) because at that time they were
> > exercising the option in the GPL which allows them to distribute it
> > to their customers only and none of those customers had redistributed
> > it when I last checked.
>
> I was recently told by someone from Ada Core that GCC for VMS can be
> built more or less straightforwardly by doing something called a
> "Canadian cross compile."  This is how they build their Ada compiler,
> and he was pretty sure they'd contributed back upstream anything needed
> to build GCC targeting VMS.
>
> I asked specifically whether the code generators in GCC were up to
> snuff for Alpha and Itanium, and he said yes; their Ada compiler
> depends on this.  (The last version of gcc for VMS I'd heard of
> existing in the wild [2.9 or so] purportedly never had an Alpha code
> generator that actually worked.)
>
> I also asked specifically whether the resulting C compiler could be
> used with the CRTL and he said yes, but you'd have to point the
> compiler build at the headers you already have, which means you'd have
> to already have rights to use the HP C compiler.  I remain skeptical
> whether GNU C could even compile those headers given all of the
> pragmas, specific alignment requirements, etc., but I suppose it's
> possible.
>
> While VAX Fortran was my first computer language, I haven't done any
> Fortran in twenty years and I don't have a very good sense of what role
> the library plays in the language.  Given that SYS$SHARE:DEC$FORRTL.EXE
> is about one tenth the size of SYS$SHARE:DECC$SHR.EXE, I'm guessing
> it's not quite as big a deal as the C run-time.  But still, getting a
> "foreign" Fortran compiler fully functional on VMS would likely require
> various kinds of glue for exit handlers, threads, and such, and, if you
> want to use native libraries, rights to use SYS$LIBRARY:FORSYSDEF.TLB
> or an independently-developed equivalent.
>
> And then you have a compiler with no debugger, so you either spend lots
> of time in the entrails of the compiler making it produce what the
> OpenVMS debugger expects, or you port gdb, or write you're own
> debugger.

I'm not sure a Canadian cross would be considered "straightforward" by
most folk.

An 'ordinary' cross compiler will be familiar to many round here. E.g.
XD Ada, you run the compiler on a VMS host but it generates code to
run on a 68K target with a particular set of runtime libraries. Note
the use of host and target.

A 'Canadian cross' compiler isn't a commonly used concept, but
basically you have a 'build the compiler' environment, and a host
environment, and a target environment. All are different. E.g. you
build the compiler on Linux (eg x86 Linux), so that it can be used to
compile (link, etc) on a VMS host, and the generated code can run on
68k.

There's more to this than may at first be obvious; I knew someone
whose job it was to do this, though not with the particular examples
mentioned above.

And then, as noted by Craig, there are the other parts of the
toolchain besides the compiler. Some of the simple ones are part of
the compiler build (binutils?). The gdb debugger isn't part of that
package (or at least wasn't, when I checked a year or two ago, gcc
4.something/gdb 7.something). In principle OpenVMS on IA64 has been a
supported gdb target since August 2012 (gdb 7.5) but I don't know how
well that fits in this picture.

IA64 is not a widely used target. Compiler optimisations for IA64 with
lots of registers and little support for parallelisation at runtime
may be counter-intuitive to compiler code which often expects
relatively few registers and decent support for parallelism in the
hardware, such as x86. Ideally this kind of stuff would be layered and
modularised and configurable in target-specific ways. But is it, in
reality?

If Anton's interest is existing Fortran applications for HPC, I'd
suggest he might want to be looking to see if any other departments in
the University might be able to make a contribution to getting the
applications updated to more applicable language standards, which may
imply more widely supported hardware. And the simplest end point
probably wouldn't be Fortran on VMS on IA64, unless the existing code
has lots of VMS-specific dependencies.

My 2p.