HP3000-L Archives

December 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Mon, 10 Dec 2001 11:14:04 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (60 lines)
Wirt writes:

[Proposal snipped]

I have to say that Wirt's proposal is the first concrete idea for a
practical and sustainable MPE continuation plan that I've heard so far
(there are some points which I would change, but they're not really worth
arguing about at this stage).

Part of this of course is that I'm a proponent of the emulation route to
getting MPE onto other hardware.

In the world of Geology the "Mohs Hardness Scale" is used to describe a
mineral's resistance to abrasion such that something with a lower hardness
number cannot scratch something with a higher hardness value.

If we were to use a similar idea in the MPE world to describe the difficulty
of implementing various futures for MPE, I think we would find that the idea
of performing a native port of MPE to IA-64 (as was done when going from the
"Classic" to PA-RISC hardware in the 1980s) has a relative hardness which is
so much greater than that of even the combined resources of everyone
involved that it is just not going to be possible to scratch the surface of
the problem.  Any effort expended in that direction will almost certainly
leave the shiny surface of the problem unblemished.

The benefits of porting MPE to IA-64 in a "native" mode are also
questionable.  MPE is only valuable to most people today because they have
software that runs on it, and they would like to not have to migrate or
rewrite that software to another platform.  But an IA-64 MPE would require a
migration process just as MPE/V to MPE/XL was a migration process.  How many
customers will want to go through this?  How many vendors want to support
two different versions of heir software again?

To a first approximation, the cost of a native IA-64 MPE is infinite and the
benefit is zero.  If we're going to print up a new batch of "MPE on IA-64"
t-shirts, then the owl needs to be replaced with a different bird.  I
believe at this point a parrot would be more appropriate, specifically that
subspecies known as the Norwegian Blue[1].

Maximizing the value of MPE for existing customers means *minimizing* the
changes they will have to deal with.  In at least the short term (and very
possibly in the long term as well) a pure emulation environment capable of
running standard out-of-the-box MPE/iX is the lowest-cost and lowest-risk
method of getting MPE onto other hardware.

As hardware evolves, the emulator can be taught to present each new
generation of hardware and peripherals to the old MPE OS as just more of the
same from its point of view.  There becomes very little reason to change the
MPE source code, and if we had to live forever with no changes beyond
today's MPE then I think that would be perfectly acceptable.  MPE has almost
30 years of development in it which has created a robust, high-value
environment, and I don't know that much more is needed.

G.

[1] http://www.pythonet.org/pet-shop.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2