[Info-vax] VMS port to x86

[John Reagan]

>"David Froble"  wrote in message news:jq3u0d$v4c$1 at dont-email.me...


>I don't understand compilers, but I'd ask, if the front end of each is 
>"sort of" portable, and all of them possibly (I don't know) work with the 
>GEM back end, then once you have the GEM back end, aren't most / all of the 
>compilers about the same amount of work ??

Mostly true depending on frontend.  The interface between a frontend and GEM 
is the same for all frontends.  Some languages have features that are unique 
so that part of GEM isn't really tested until that particular frontend is 
available (ie, Pascal's VARYING OF CHAR).

For Pascal, I think I got the first cross-compiler running in just a day 
once the cross-built GEM was available.   Same for a native compiler when I 
got a BLISS cross-compiler and cross tools (linker, librarian, libraries). 
And natively-built compiler just worked when I ran the build .COM file on an 
OpenVMS Itanium system.

Most of the frontends do have a small bit of target awareness for certain 
aspects of the Calling Standard.  While GEM knows about preserved register 
sets, exception handling, etc., the building of descriptors is a joint 
operation between the frontend's and GEM.

And at least for Pascal, we use GLOBAL REGISTERS (oh no, no that topic 
again!) so I had to add an

%IF HOST_(IA64,VMS)
%FI

section to the .R32 file that contains a bunch of macros that expand to 
different things based on host and BLISS LINKAGEs that vary between hosts.

And a companion

%IF TARGET_(IA64,VMS)
%FI

to control things about the generated GEM intermediate language.

I believe some of the other frontends do not isolate things as well as we 
did them for Pascal.

The RTLs are another piece of work.  Some are very "portable" in the OpenVMS 
sense (ie, they use standard RMS interfaces, etc.).  However, there are 
always a handful of places that have target awareness (ie, setjmp, longjmp, 
Pascal's non-local GOTO which maps mostly on to SYS$GOTO_UNWIND64, etc.)

NB: Nothing I mentioned above applies to the Macro compiler.  The Macro 
compiler uses a totally different (and very target instruction set specific) 
interface to GEM.  The high-level GEM interface is not sufficient to 
describe Macro.  The decision was made very early in GEM's design not to 
clutter the interface with such stuff (like cross jumping between routines, 
condition codes, etc).  So Macro bypasses about 2/3rds of GEM and attaches 
to the last third that does instruction scheduling, object file writing, 
debug writing, etc.  Macro is essentially contains its own optimizer and 
code-generator.  I did however cut-n-paste several code sequences from the 
GEM sources into the Macro compiler sources.