Pondering how to explain my idea so everyone will get it ...

On 9/14/06, Gavin Scott <[log in to unmask]> wrote:
> Pete ponders:
>
> > Running Classic binaries on PA-RISC was the best performing emulation
> > I have ever seen.  QEMU is not going to give you nearly the
> > performance.
>
> CM on MPE/XL was probably as good as it gets in terms of emulated speed
> versus native speed on the same platform.  In fact I believe it resulted in
> HP having unrealistic expectations about PA-RISC emulation on Itanium.
>
> In the case of emulating an HP-3000 though, you care only about emulated
> performance versus native performance ON THE ORIGINAL HP-3000.  Most 3000s
> are so amazingly slow by modern standards that there's not likely to be a
> big problem exceeding the original performance even with a pure emulation of
> the hardware platform.  And this situation just gets better over time.  If
> it's not fast enough today, just wait a year.

You have a point there, if you want to just get-by for a couple of years.

> In terms of relative difficulty of an emulation solution that allows you to
> run the existing MPE/iX OS and applications without any changes, versus
> developing a whole new MPE compatible OS, the emulator program would be
> miniscule in size when compared with MPE, and the work to be done would be
> much better defined.  So I still believe a software emulation of the HP-3000
> hardware platform capable of booting and running unchanged MPE/iX is a
> perfectly viable idea.  Whether it does anything to "save MPE" or not is a
> different debate.

Once again, I am not talking about developing an MPE compatible OS, or
any OS for that matter!  Only to create a USER MODE MPE environment
running on top of Linux.  The intrinsics are standard MPE on the
calling side, and pure Linux environment on the inside.

> > The other issues are getting the source for MPE in total, which appears
> > to have some problems with inclusion of 3rd party software and the fact
> > that HP doesn't want to spend the time to clean up the code for release.
>
> For an emulator, you need no source code.  You simply emulate one or more
> HP-3000 models and you run the OS unchanged.  You need only a runtime
> license as you have today, which should not complicate the included 3rd
> party software licensing.

There is nothing simple about emulating even "easy" CPUs like the
Intel chips.  The various PA-RISC CPU implementations are a whole
magnitude harder!  Also, I personally would not want to depend on HP's
good nature to offer me a runtime license going forward.  As far as I
can tell, they want to put the HP3000 and MPE behind them, far behind
them!

> > Another problem going forward, is getting hardware drivers for new
> > server peripherals.
>
> A simulation of the hardware solves this problem completely.  You simply
> teach your hardware simulation program to make a LudicrousTapeXVII drive
> with a sub-ether trans-light SCSI 23 interface look like a DLT4000 with a
> single-ended SCSI interface.  MPE already supports one or more devices of
> each "type" (disk, tape, network, etc.) that you are likely to ever want to
> connect, so the emulator simply maps the behavior of your new exotic
> peripheral into one of the already supported devices in MPE.  No changes to
> MPE are ever necessary.

Now your emulator has device drivers built in?  Have you ever written
a device driver?  Are you just going to ignore the hot new
functionality that your new peripheral has, and you just spent good
money for to treat it as some "dumb" 20 year old device?

> > To get anywhere near native speed in hardware emulation, you have to
> > have some very talented CPU design engineers to design it into the CPU
> > circuitry.  Doing it in software is always going to take a major hit
> > in performance.
>
>     928LX:    48,000,000 instructions per second.
> Modern PC: 3,000,000,000 instructions per second.

MIPS do not equate between architectures.  But, I do agree that a
modern desktop has all of the CPU horse power needed.  Database
performance would require something more than a desktop.  I assume you
are aquainted with the difference between CPU performance and IO
performance.

> You can waste 60 native instructions emulating each PA-RISC instruction (and
> this only has to be an average of the most common instructions) and still
> come out ahead.  The numbers are only approximate of course.  And again this
> "problem" gets better every year.

The viability of MPE solutions are not getting better every year!
Having a user mode MPE environment on Linux gives you a starting
point.  The environment can be enhanced from that point forward,
exposing only the needed or usefully functionality included in Linux
as necessary, while maintaining a clean and simple corporate
application development platform that is MPE.  When you have access to
full Linux, what server limitations do you have?

> > And, if you are taking a major hit in performance, how do you stack up
> > to the competition?
>
> Ah, yes, well, if you want your MPE to compete in performance with, say,
> modern Linux on a modern x86 platform, because you think you have a hope of
> convincing new customers to run MPE, then I think you have a much harder
> struggle ahead of you.  MPE is unlikely to ever again "compete" with any
> operating system.  Now you might have an *application* (that can compete
> with other *applications*) that happens to have MPE under it, but there's
> just no hope for competing OS vs. OS at this point.

I have never suggested creating another OS, nor using the OS part of
MPE!  In fact I have recommended against it from the beginning!!!

Let me make this clear:  I AM ADVOCATING RUNNING AN MPE USER MODE
ENVIRONMENT ON TOP OF A FULL OR CUSTOMIZED LINUX DISTRIBUTION, AND
USING MPE INTRINSICS AS THE WALL BETWEEN THE TWO!!!  No recreating a
kernel, device drivers, scheduler, dispatcher, SMP/cluster/grid
enhancements -- Linux already has all of that, and there are some very
capable people working on those things either as a voluteer or in a
well paid positions.

> > Which brings me back to my original idea.
>
> So, unfortunately, I have to say that ideas are a dime a dozen and of
> practically no value when compared to some actual effort.  As the old saw
> goes, genius is 1% inspiration and 99% perspiration.  So come back and show
> us when you have it working.

So you would be interested in the solution, as long as someone else
does all the work?  That doesn't seem like the Gavin I have heard
about, but I guess people change.

> All of these ideas were discussed at length five years ago.

Could you point out where my ideas were already discussed?

> We had the emulation discussion (at great length).  We actually had the
> "let's implement an MPE file system in Linux" discussion (several times).
> What it comes down to is that nobody has yet done any of these things after
> five years.  There exist several commercial packages designed to simplify
> migration of MPE applications to other platforms that implement various
> parts of MPE functionality (Intrinsics, CI language, etc.) but none of them
> can be said to "be MPE" in any significant respect.
>
> If you think the world needs MPE extensions to Linux then by all means go do
> it.  That's where things like this actually come from.  You might not have
> to do too much before you get other people interested in helping, but you
> have to have something you can show to people and say "come look at this,
> isn't it cool?".  Ideas are fun, but other people volunteering to implement
> your ideas for you does not happen in practice.

Not looking for volunteers to implement for me.  I am looking for
interest by people that would be part of the market to support the
venture, or want to be part of the solution.  Both have to be there.
I personally don't need this as I have moved on.

I saw OpenMPE, remembered with some fondness MPE as a custom corporate
database application platform.  I reviewed what I could find in the
OpenMPE archives on maintaining MPE into the future.  I did not see
anything that would work, and agreed with most of the arguments why
they wouldn't.  I then took the time and energy to map out a plan I
thought was viable based on my knowledge and expertise as an old MPE
internals expert (actually worked reading system dumps and patching
MPE when HP was to slow to respond to banking customers), and some
current expertise in Linux.  I don't need help designing or leading
the solution, only need to know that it is worthwhile pursuing and to
verify that I haven't missed anything in the design before I start.

If there is not enough interest in the market or to assist in making
it happen, fine.  I have wasted a few hours of my time, but the effort
won't otherwise impact my life.  If you can find a hole in my ideas, I
am all ears.  But, please read my purposal carefully.  I do not
believe I have gone over anyone's head with a good understanding of
MPE and OSs in general.  I will be happy to explain anything that you
do not understand, but it has been quite awhile since I have done any
system internals work on MPE.

- Pete