[Info-vax] The (now lost) future of Alpha.

[John Reagan]

On Monday, August 6, 2018 at 8:52:26 AM UTC-4, Simon Clubley wrote:
> On 2018-08-06, Craig A. Berry <craigberry> wrote:
> >
> > No, the suggestion was that maybe on IBM mainframes they aren't
> > syscalls. They may be implemented in some other library, maybe even the
> > C library.
> >
> > My point was that a compiler may well make use of various kinds of
> > native services as well as C library functions, and the C library
> > functions will themselves in many cases be implemented in terms of
> > native services. I'm sure various of the VMS compilers make use of OTS$
> > and STR$ and LIB$ and SYS$ routines in places even if they are written in C.
> >
> 
> I suspect many of the VMS compilers use RMS directly instead of
> the C library functions to read program source code as well.
> 
> Simon.
> 

Correct.  The GEM interface used by all the frontends (GEM_TI, for text input) is written in BLISS and uses RMS (on OpenVMS of course).  The equivalent GEM_TI code that we used to use on Tru64 was written in C and used fopen, etc.

The VMS code is a little more interesting in that it needs to deal with RMS stickyness, DCL comma lists, global vs local qualifiers, etc.

The C/C++ frontends themselves call the CRTL's TO_VMS parsing code to get the platform-specific format to pass into GEM_TI_OPEN for example.

On x86, those GEM interfaces (others include command line processing, error generation, etc) will be moved over and continued to be used.  So none of the existing frontends will have to change.

We'll have to touch the clang frontend at some point and need to decide how much to leave with calls to the CRTL (ie, fopen, fread, etc) vs what needs to use the GEM interfaces for command line processing, etc.

Exactly what we did for the Intel C++ compiler that we use on Itanium by the way.