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:
Jim Chance <[log in to unmask]>
Reply To:
Jim Chance <[log in to unmask]>
Date:
Thu, 14 Sep 2006 17:01:36 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (324 lines)
Near the bottom of your posting you say:
"I personally don't need this as I have moved on."

Chuckling......really? Are you sure?


--- Pete <[log in to unmask]> wrote:

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


-----------------------------------------------------------------------------------------------------------------------------------
  Seeking PERMANENT employment within a shop that has any of the following: HP3000, Macola, Jobscope, MS SQL in the states of: OH, TN, GA, NC, SC, FL. 
   
  Titles of:
Senior P/A, S/A
MS SQL Admin.
IT Director, Manager, project leader

OR >>>> HP3000 Contract/Consulting anywhere in US. 

Can you help me out?

419-651-6704   or [log in to unmask] 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

ATOM RSS1 RSS2