Richard on the very popular thread:

> Just some quick points for now.  Emulated environments have
> become much more stable and have good performance in
> recent years.

CM on PA-RISC as one of the best examples....  Gavin's favorite
PC software another....  If carefully done and tested by competent
people, I have little concern in the area of emulator stability....  And
by the time anybody will actually want to use it for anything more
than beta test, hardware-driven performance of a pure emulator
may be "good enough" for even medium-large sites....


> Second, most of the points below (open source) could be later
> goals, but the immediate need is for MPE to run on a non PA-RISC
> and the emulator is by far the simplest way to achieve this.

Reality-check time:  As others have mentioned, a "pure emulator" is
the *ONLY* way MPE will run on anything other than PA-RISC in the
next few years:  A port to IA-64 on the order of what CSY planned
but has now dropped for clearly stated reasons might approach 100
work-years.  The effort to get a pure emulator up and running will be
a small fraction of that.  If and when the world can be shown a "for
real" pure emulator actually running MPE on IA, and if that is well
received, then it might be possible to re-visit long-term possibilities
for incrementally improving the efficiency of operation on IA.  Any
attempt to skip the critical pure emulator step and do *anything* else
first is a non-starter and doomed to failure, IMO....


Gavin probably said it as well as anyone:

> ....  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.       ..........

Delete "almost", IMO...

Also as Gavin said:  What we want is not to "migrate" end-user
system to IA-64, but to run what they have right now on IA-64
hardware;  as much as possible without MPE compilers or
executables even *knowing* that they are running on IA-64.  Virtual
MPE, or VMPE, as it were (pronounced "vemm-p-e" (old Norwegian
sidevar (sorry:  It's late) ) ).


> I applaud Wirt for coming up with a practical way to evolve MPE.

Ditto....


> One of disagreement with Matt, New MPE should not be tied
> closely to hardware. That was it's power, but also it's downfall.

I respectfully but strongly second Richard on last above:  CSY has
said they will continue to enhance MPE for the next two years.  We
may not get the rate of enhancement going forward SIGimage/SQL
enjoyed over the last couple years, but I'm going to let myself be
optimistic and hope that it won't be trivial either.  I.e.:  I doubt that
any existing HP 3000 site will find they need a critical enhancement
that hasn't already been done or will be done while HP is still active.
....  remember the US 1992 campaign "It's the economy, stupid"
slogan ??..  well, in this case (absolutely no offense intended to
anyone):  It's the emulator....   the emulator....  the emulator....


> One other point about Wirt business model, many business and
> government institutions may have trouble investing in a invisible
> product or even to become a members of a formal LLC. I suggest
> a software product of low cost (donated?) but real potential value
> (to justify the price) be sold with the profits invested in the New
> MPE.

Anybody who works for the Federal Government (and maybe for
quite a few large private companies) should recognize this as a
very good idea:  If there is a real product out there that can be had
for a relatively small sum (say.:  $1000;  or at least under standard
$2500 bankcard limit), then it might make it's way through the
purchasing hoops...  "Investment", OTOH:  Not a chance;  no way,
no how....


> The other alternative would be a virtual conference of joining an
> organization, or subscribing to a newsletter.  Any of these things
> could be leveraged into a model for something we could buy to
> support the New MPE project.

Richard's really on a roll today:  More good ideas:  Training, a
technical journal, employee professional development, a.....   a....:
A USER GROUP MEMBERSHIP (shades of SuperGroup and David
Brown (no:  NOT those ghosts;  and let's NOT go there) )....


Before that Matt Shade wrote:

> Anyway, I think the only way to do it right is to actually write MPE
> basically from scratch. Sure, HP would definitely have to help in
> providing the system structures, IO maps, memory tables, etc.

Gavin already gave the definitive answer....

Just one data point that may illustrate (it's so long ago that any NDA
expired):  In early 1987 I went down to HP - Cupertino so HP could
prove to my senior management that our CM Fastran code would
run and run acceptably well before we locked in the purchase of
our first MPE/XL box (one of the short-lived 930s;  that CSY almost
immediately turned into a 935).  At that time I was directly told by a
senior HP engineer that CSY had over 600 work-years into just
MPE/XL at that time (again:  this was 1987;  and this was just in the
"port" of MPE/V to MPE/XL).....


> ........  For someone to move off a 969 4-way, it'd have to be
> better than BETA.

But nobody will *have to move* off a 969-400 for many years; at a
minimum HP will itself "support" PA-RISC MPE for five more years.
Heck, I expect our old 959-400 will still be running production here
at Keyport for some time yet;  not only that, but we will (if not
derailed by politics) probably double the number of users and
maybe then some during that time....      :-)

Ken Sletten

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