[Info-vax] Moving away from OpenVMS

[David Froble]

John Reagan wrote:
> 
> Again, don't forget that you need BLISS and C just for the OS and you'll 
> want all the rest of the compilers for the customer base.  GEM's old x86 
> target was 32-bit only, just did the things that Visual Fortran 
> required, and generated Windows object files and Windows debugging 
> info.  All of that would need fixing.  And switching to some other code 
> generator (gcc, LLVM, open64) might work but I'd have to think about it.

I seem to recall that there have been some things in the past that sort of never "made 
it".  Macro 32 and maybe Bliss, to implement RDB on windows, or something like that.  It 
has been maybe 10+ years so memories may not be 100% accurate.  But such stories seem to 
indicate that Macro-32, Bliss, and such can be implemented on x86.  I can guess that 
something such as SimH which emulates in software the VAX instruction set might be a more 
difficult task.  As for C, unfortunately, we already got several flavors of that.

> As I've mention before, the smaller register set (as compared to Itanium 
> and Alpha) causes more rework for facilities like RMS that currently use 
> lots of GLOBAL REGISTERs to pass around implicit arguments between 
> routines.  Since the Alpha and Itanium compilers were able to make it 
> all work (there is some funky spilling involving GLOBAL REGISTERs on 
> Itanium and corresponding funky-ness in the unwind descriptors and LIB$ 
> calling standard routines to cover it up), nobody had ever attempted to 
> clean up all those RMS internal interfaces.  I suspect a move to x86 
> would force that issue.  It would also impact user code as well (any 
> Macro that specified non-standard arguments to .CALL_ENTRY or 
> .CALL_LINKAGE).
> 
> So while the Itanium port only required touching of 5% of the code (I 
> think that's the number that Clair Grant used to quote), I would guess 
> the number would go up to at least 25% of the code for x86 (including 
> some rather important code).
> 
> On the bright side, x86 doesn't have NaTs. :)
> 
> 

Regardless, it's an exercise in software engineering, and that's always been doable.  What 
hasn't been available is the resolve to fund and do it.

It's the lack of resolve that puzzles me.  We're not talking about some mistic thing here. 
  We're talking about something entirely do-able.  The arguments are the same, at least to 
me, as they were 10-12 years ago.

As an example, the Codis application package.  It's been in existence and continually 
upgraded for longer than VMS has been around.  I've been asked more than once what it 
would take to port / re-implement Codis on Windows.  At first I tried to explain the 
difficulties.  The windows environment is different enough that it would be a 
re-implementation, not a port.  People being people, if they don't like an answer, they 
keep asking until they get an answer they like.  So I finally came up with the simple 
answer of $50 million.  For at best a sideways move, and most likely would lose some 
functionality.  That usually ends the discussion.

To digress a bit, it's not that the customers demand that the system run on windows, they 
just want a windows user interface, and I've told them that a client / server model could 
easily present some selected functions in a windows user uinterface, or a browser based 
user interface.  Big problem there is nobody can make up their mind, and if I choose, it 
will be the wrong choice.

Regardless, and I'm not claiming any of the dollar amounts are correct, but if it cost $50 
million to get Codis on another platform, and $30 million to get VMS on x86, wouldn't the 
better business case be to port VMS?  That is just one application, and I've got to 
consider there being hundreds or thousands of others.  So from that perspective, I just 
cannot understand why VMS is not already running on x86, nor before the itanic port could 
I understand abandoning Alpha.