OPENMPE Archives

September 2006

OPENMPE@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:
Reply To:
Date:
Wed, 13 Sep 2006 14:57:44 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
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.  QEMU works great if you are testing non-native binaries,
but not for production environments.  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.  Another problem
going forward, is getting hardware drivers for new server peripherals.
 Who will write them?  This is hard problem.  Other OSs continue to
move ahead with new hardware technologies.  Would OpenMPE have the
resources to keep up and remain competitive?

MPE is on the verge of death and PA-RISC is sliding downhill.  Linux
is supported by HP, IBM, and every other hardware or software server
manufacturer in the world that isn't MS only.  All of the drivers are
there, it is a top performing kernel and OS, there are a multitude of
excellent development tools available, to the point that your number
of choices becomes a problem just deciding what toolset to use.  Many
high end tools, like Eclipse (http://www.eclipse.org/), are developed
on Linux and ported to other OSs.

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.  And, if you are taking a major hit in performance,
how do you stack up to the competition?

Even if you overcome the emulation performance problems, you are still
having to compete with MS, Linux, AIX, HP-UX, Solaris, and zOS.  Can
OpenMPE match the resources being used on these?  Actually, all are
losing market share to MS and Linux.  How do you expect to compete
against either of these OSs?  Why reinvent not only the wheels, but
the nuts and bolts and everything else that goes into a full fledged
OS and try to be competitive in the marketplace?

Which brings me back to my original idea.  Use Linux as the chassis
and build a user mode MPE interior with all of the familiar controls,
layout, and easy-of-use design.  The key in a nutshell, is to build a
wall of MPE intrinsics separating user mode MPE on one side, and a
Linux platform on the other.  Between 85% to 95% of MPE/iX can be
thrown away as not only unnecessary, but replaced by better components
of a Linux platform and with no ongoing support costs, with free
enhancements, and with free support of new server hardware and
peripherals.  In this scenario, you are not trying to beat Linux
(which even MS has failed miserably to squash for over 10 years), you
are joining Linux, and acquiring all of its resources by default.  I
still haven't seen anything that says this idea won't work, nor have I
seen any other idea that is anywhere near as economically feasible.
If I am wrong on either account, please enlighten me.

- Pete


On 9/13/06, Lars Appel <[log in to unmask]> wrote:
> Pete wrote...
>
> > I saw where people were talking about emulating HP3000 hardware on
> > Linux.  Bad idea for all of the reasons given, monstrous job and would
> > be very slow in execution.
>
> While talking about the emulator approach... just recently
> I stumbled across an Open Source emulator called QEMU... which
> seems to cover several CPU types, not just PA-RISC... yet...
>
>   http://fabrice.bellard.free.fr/qemu/
>
>   http://homepage.ntlworld.com/wholehog/stuart/qemu/target-hppa.html
>
> Makes me wonder if this could be an interesting starting point
> for trying to get a PA-RISC hardware emulation implemented...
>
> (not meaning to say "no" to Pete's thoughts and ideas)
>
> Lars.

ATOM RSS1 RSS2