[Info-vax] VMS and the embedded world, was: Re: PowerX Roadmap - Extended beyond 2020

[John Reagan]

On Sunday, October 23, 2016 at 9:18:45 PM UTC-4, clairg... at gmail.com wrote:

> 
> Porting VMS is a huge job but we are making it easier each time. Will it ever be like porting a portable OS written in C? No, absolutely not, but it is a lot more "turn the crank" than you might think.
> 

For those who are interested.

For BLISS, is is the powerful macro language built into the frontend.  It is context-sensitive so even trying to write a pre-processor in some more expressive language (Perl, Python, etc.) makes is a difficult task.  For example, when expanding an iterative macro, the compiler has to decide on a separator (ie, does it insert a free "," between times or something else).  That depends on where in the BLISS language the macro is being expanded.

For Macro, it is mostly the fact that you can jump between routines.  You can come into routine A, jump to B, jump to C, indirectly jump to D or E, and finally return from F.  That is difficult to express in C (or just about anything else).  We had a translator company try years ago with such a piece of Macro, and the resulting C looked like:

int B(int R0, int R1, int R2, you get the idea...);

and kept passing those parameters from routine to routine.

The Macro-32 cross-jumping is a real pain on both Alpha and Itanium.  On Alpha, all of those routines need their R27 linkage pointer to be the same.  On Itanium, all of those routines need their out0-out7 registers to be the same so they all need their 'alloc's to be the same.  The Macro compiler has to build an elaborate flow graph and walk it several times forward and backward to look for available registers in basic blocks, lifetimes of VAX condition codes, and which PUSHLs are putting values into parameters vs actually building some data structure on the stack.  And on Itanium, some of those PUSHLs might involve NaTs and need even more special-handling.