[Info-vax] VMS port to x86

[David Froble]

abrsvc wrote:
> On Tuesday, March 20, 2012 11:20:31 AM UTC-4, David Froble wrote:
>> Howard S Shubs wrote:
>>> In article <4f67e979$0$4672$c3e8da3$3a1a2348 at news.astraweb.com>,
>>>  JF Mezei <jfmezei.spamnot at vaxination.ca> wrote:
>>>
>>>> I fear it may be too late to save VMS.
>>> We can always hope they'll release the source code for some earlier 
>>> version, such as 7.3.  Then we can have some fun.
>>>
>> There already exists a Macro32 compiler, used on both Alpha and itanic.  Don't know what 
>> language it's written in, but with recent trends, probably (hock, spit) C.
>>
>> Same argument for Bliss.
>>
>> Just being able to compile the code probably isn't the only requirements.  There is most 
>> likely some things that depend upon the underlying hardware.  That's a conservative 
>> assumption to make.
>>
>> Not going to try to guess what all the problems might be, but, I've got to think that it's 
>> not just a complete re-write.
> 
> As with previous ports, there are many things involved.  Simply porting the compilers won't be enough.  The Macro compiler and the bliss compiler use the GEM backend code generator.  That too would need to be developed.  Also, tehre are "hardware assists" that are used to implement some of the VMS "isms" that exist.  For example, I don't think that the x86 has the concept of 4 operating priv modes.
> 
> Dan

Forget about modes and such, that's just details that could be addressed.

All I was trying to say is that there is much that would require little or no re-working. 
  As with NT, there was the code dealing with the OS, and there was what I think they 
called the "hardware layer".

But VMS isn't just the OS.  There are all the tools, languages, and such that make up the 
total package.  If you cannot get all of it, then why bother?  Frankly, I'm more than a 
bit tired of being told to "program in C and forget the other languages".  If that's all I 
wanted to do, I can do it on Unix and windoz.  Some things I can do on Windoz much easier.

As pointed out, there is the back side of the GEM compilers.  Sure, the front end stuff 
should work, syntax checking and parsing and such, but you then have to produce code that 
would run on the target hardware.

It would not be an easy job, or better to say it would not be a cheap job.  If HP cannot 
justify doing it, then I doubt anyone else could justify the cost.

In terms of cost, I cannot know what it would take.  I have some ideas, but, there are 
other issues.  If HP would have retained the team that did the IA64 port, then perhaps 
they could have done the job at a reasonable cost.  But they didn't.  And now it's 
possible that the critical knowledge no longer exists at HP.  That might be the real problem.