I would like to add the shops that use VMS-native compilers (Fortran,
Cobol, Pascal, etc). If GCC delivers a non-VMS object format, it is of
no use at all. Even if it did - what would be the benefit (except the
cost)?
GCC delivers a VMS object format. With IA64, OpenVMS uses close to the same ELF format that LINUX and other platforms use. Some extensions have been added to support VMS specific features, and those extensions have been fed back to Intel for eventual inclusion in the specification.
This brings a possibility of being able to compile and link images for another IA64 operating system, even though that is not something that was specifically tested.
A Unix-like interface would indeed be handy - but the GNV CC-wrapper does just that, if I'm informed well. Take a look at http://www.4ovms.dyndns.org/phpbb/viewtopic.php?t=17 for an overview.
But not a unix-style one in stead of a VMS-style one, and a decent HELP specification. That rules GCC out - for the moment.
The last GCC implementations for VMS that I saw had a VMS style CLD on them. Unfortunately who ever produced the last binary for them seems to have misplaced the source. I do not know if anyone has recreated the missing source for the wrapper code.
If my faulty memory is correct, there was also a VMS help file for this. That VAX is powered off at the moment to conserve power.
In my rsync tests on http://eisner.encompasserve.org/~malmberg/rsync/ there are tpu routines that will attempt to convert a UNIX man page in to .RNO or .RNH file, and the .MMS file should show how to convert them into a .HLB. It still does not handle every syntax found, but it will do the bulk of the conversion, and can usually be tweaked for the rest.
The compiler is one thing. What about: * exception ahndling (status, messages...) * RECORD-based IO in stead of STREAM-IO * Naming conventions.
GCC on VMS uses the existing DECC$SHR routines for most of it's runtime, so the compiler does not even have to deal with those issues. On VAX, use the "NO PREFIX" library for linking with the DECC$SHR.
One issue is that GCC for VMS when last seen could not use the .TLB files containing the C headers which are now supplied with VMS. The two problems are that it can not read the .TLB files, and that the header files are written to expect a HP C compiler.
These are more important issues than just the compiler.
You can port a program so it runs, but if it cannot co-operate with
natively built programs properly, the effort is useless.
One of the big attractions for GCC is that it provides a back end code generator for other programming languages or for cross compiling.
Languages that use GCC do not convert to C first, and then compile, their front ends call a back end to get specific code patterns to generate. The resulting code is then fed to to the GNU Assembler.
Unfortunately while that back end code generator is open source, the documentation on how to use it is several generations out of date.
-John [EMAIL PROTECTED] Personal Opinion Only
