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 *