[Info-vax] VMS porting/rewrite, was: Re: [OT] Wirth style languages, was: Re: Obscure Ada compiler vendors?

[Craig A. Berry]

In article <kk11j5$etr$1 at dont-email.me>,
 Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:

> On 2013-04-08, Keith Parris <keithparris_deletethis at yahoo.com> wrote:
> > On 4/4/2013 11:01 AM, Stephen Hoffman wrote:
> >> Rewriting all of OpenVMS?  That'd lead me to this state:
> >> <http://www.youtube.com/watch?v=3L6i5AwVAbs>. Even if you were to be
> >> successful with a rewrite, once you're done with that very substantial
> >> and years-long effort and investment, you would have something
> >> approximating current-day VMS. Not the features and functions that
> >> folks would would want and would expect after all those years.
> > ...
> 
> This is talking about a rewrite of the code from the ground up, maintaining
> user level API compatibility, but with different and more modern internals.
> 
> >> The rest of the
> >> market is not standing still here, and you're talking about a project
> >> that took three or five years last time (Alpha to Itanium) for a fairly
> >> straight port with very few changes, and with an engineering team that
> >> was very familiar with VMS assigned to the effort full-time.   ~Thirty
> >> million lines of Bliss and C and Macro32 is a huge project to
> >> reconstitute.
> 
> This is talking about a port of the existing code base to a new
> architecture.

No it's not.  What do you think the word "reconstitute" means?

> 
> These are two separate issues and people are mixing them up.

No, actually, you seem to be the one mixing them up.  The reason that 
previous ports to new architectures have come up more than once in this 
thread is as a measure of scale.  Whenever OpenVMS Engineering was 
faced with getting VMS running on a new architecture, they considered 
rewriting major portions of it, but rejected that option.  Whatever 
difficulties there were in porting MACRO and BLISS (and of course the 
first time, converting MACRO from an assembler into a compiler), moving 
firmware functionality into the OS, messing with scary exception 
handling differences, and other porting challenges, doing those things 
was always less expensive, more achievable, and more compatible than 
undertaking a major rewrite.

Those were major challenges, but tiny in comparison to the suggestion 
that an independent group of volunteers could rewrite it all from 
scratch without access to HP's source code.  I'm all for rewriting it, 
but steadily, incrementally, as new capabilities or new target 
architectures make it necessary.  It would be nice if HP would do that. 
 It would be nice if HP would let someone else do that.  I will 
continue to hope for either, but expect neither.