Christian Lheureux wrote:
> Hi Rome, and welcome on The List!
>
> You wrote:
>
>
>>I think we're all missing the point here...
>
>
> And we've been missing it big time .... <sigh> for a long, long while.
>
>
>>If I may read between the lines, what we really want, is to re-create
>>MPE on other platforms.
>
>
> Re-create or emulate, whichever makes sense. The ultimate goal is being able
> to run present MPE applications onto "something else" (intentionally vague
> denomination used. "Something else" could, in theory, be either a native OS
> (re-create MPE) or an emulator (emulate MPE). The subject of the emulator
> has been battered to death since 11/14/01 (The Death Sentence), and it
> sounds pretty much easier to do than a native OS.
>
>
>>Currently, the best we have out there is OpemMPE.org.
>
>
> Agreed.
>
>
>>Unfortunately, HP will really never let this happen,
>>unless they can make some money out of the transaction, or they feel
>>that doing so will hurt their compitetors.
>
>
> This is mere suspicion, but there are a few facts that help fuel it, if not
> substantiate.
>
>
>>I don't believe these issues will get resolved.  So, we're looking at
>>MPE dying a slow death (painful for some of us).
>
>
> Agreed, again. Though my business no longer depends on it, I've done MPE for
> the last 23 years of this lifetime, I've enjoyed it, and it kind of breaks
> my heart to see it suffocate.
>
>
>>I propose that we start thinking about "re-developing MPE on our own".
>
>
> That subject has been extensively discussed on the OpenMPE-L in the
> late-2001, early-2002 timeframe. If you have access to that period's
> archives, you may want to read the details there. And, since most OpenMPE-L
> subscribers are also 3000-L subscribers, I'm damn sure lots of people will
> supply whatever information you may ask.
>
>
>>Most of the O/S can be developed over (on top) of some other operating
>>system for starters.
>
>
> Not that easy. Some parts are relatively easy to do (read : TurboImage,
> e.g.), some others are tricky (e.g. I/O drivers). Unless you emulate MPE
> rather than re-develop, you are going to run into quite tricky problems in
> some of the deeper parts of the OS. I'm specifically concerned with whatever
> interfaces with non-HP3000 and non-MPE specifics, mostly the I/O system. One
> example : these days, the largest physical disk an MPE box can handle is
> about 400 GB. What do you do once you have a more than 400 GB baby on the
> market ? What do you do when you want to configure in a more than 400 GB LUN
> hosted on a SAN array ? At some point in history, MPE was developed and
> maintained by a team of dozens of engineers, if not more. I can't see a
> business case where we (read : OpenMPE) could assemble so many competencies
> and still churn out a profit.
>
>
>>At some point, once the code base is good enough,
>>one can start thinking of creating a "real" operating system (on other
>>hardware/platform).
>
>
> This may be the hardest way. The choice of the emulator vs. a native OS was
> justified by abstracting most, if not all, of the I/O layer, which I
> referred to above as "interfacing with non-MPE specifics". If we emulate
> MPE, we can abstract the /O layer. If we re-write MPE, we have to handle I/O
> and solve hundreds of problems for good. This is going to take man (and
> woman-) power, time, dedication, and money. One of the problem we would have
> to face : how do you hire talented, skilled, trained MPE engineers without
> the promise of a decent paycheck ?
>
>
>>If we can create the CI (shell) that can execute all MPE commands, then
>>this would be a good start.
>
>
> That's a very good starting point, I certainly agree. However, it may just
> be the tip of the iceberg (there are many more issues), the easiest part to
> do (most MPE commands could, for instance, be scripted on, say, Linux or
> HP-UX), and not sufficient by itself (you have to handle process creation,
> code loading, program execution, NM-to-CM switches, deal with executable
> code format, link XLs at run-time ....). remember, the ultimate goal is to
> keep the applications with minimal, or no modification, other than, say, a
> recompile and re-link.
>
>
>>At least it would give all MPE folks out
>>there an environment that they can use on various other platforms.  In
>>order for this to happen, one needs to start re-creating the
>>functionality built into the system XL: developing functions such as
>>FOPEN, FCLOSE, and so on.
>
>
> Good ! Now, you're beginning to grasp some of the complexities of what's
> needed to make it happen ! The file system, as you implicitly mentioned it,
> is a very good case of what has to be done. For instance, you know that
> Linux and Unix have only one file type : byte stream. MPE has four : byte
> stream, fixed, variable, undefined. If you want to handle MPE files on top
> of another OS, i.e. emulate, you need to have built-in emulators for the
> three non-byte stream types. You may want to find inspiration in what was
> done to emulate these file types when Posix was introduced a decade ago. But
> you may need to use some of the MKS code that was built into the Posix shell
> and utilities code at the time. So you may also have to deal with non-HP
> code.
>
>
>>The other issue here is what language should be used to develop the XL.
>>  Although there are many out there, I suggest a language that is
>>low-level, fast, free (open-source), and housed on many, many operating
>>systems.  Given these limitations, there are not that many languages
>>that can be used.
>
>
> If I were to recommend a language, I would push Pascal, for at least 2
> reasons : 1) I have used it extensively and I could therefore have a
> contribution in the overall project, and 2) MPE is mostly written in Pascal
> and, if we ever get access to source, we would have to deal with Pascal
> anyway.
>
> But these days the reality is a bit different. Pascal seems to have
> disappeared from the radar screen, and every young pup right out of college
> is trained in C/C++. So the trend is more toward C than toward Pascal. I
> can't think of any argument to push forward any other language.
>
>
>>Although my favorite languages are "Wirth" flavored (modula-2, pascal,
>>etc), I propose going to some assembly (although, admittedly modula-2
>>produces the fastest and smallest code I have seen [if written properly]).
>
>
> IMHO, there is minimal need for assembly code. MPE itself has precious
> little of it.
>
>
>>The two assemblers that come to mind are: NASM, which runs on just about
>>ALL platforms, and, my current favorite: HLA (high-level assembler).
>>HLA is not your usual asm: it has a standard library similar to c++
>>(stdlib), conditional constructs (if, else, etc), and very enjoyable to
>>code in.
>
>
> I won't comment there, I don't know either of them.
>
>
>>I would be willing to join such a group, and start the ball rolling on a
>>new MPE.  This new Open-source MPE should be available for free,
>>downloadable from the internet.  Version 1.0 should have, as a minimum
>>the CI.
>
>
> Once again, try to get access to the OpenMPE archives of late-2001,
> early-2002. Everything has been discussed there.
>
>
>>Any takers?
>
>
> My best guess is that any company would take it if two pre-requisites were
> filled : 1) make the venture profitable and 2) gather the appropriate core
> competency team. Unfortunately, time is running out on both issues, with the
> installed base fleeing en masse to other platforms and MPE developers
> fleeing en masse to other occupations.
>
> As usual, I'm available for further comment and discussion, either public or
> private.
>
> I hope you've been patient enough to read my post down to its end. I know
> it's long, but the subject deserved that.
>
> Best Regards,
>
> Christian Lheureux
> Head of IT Infrastructure BU
> BTW Computing
> HP Business Partner
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
Thanks to Christian and Ray for replying to this...

Excellent points raised (yes, I read the entire reply).

During my HPLAB days, the language of choice was MODCAL, which was
essentially pascal with various extensions such as default parameter
values, and other goodies that pascal lacked.  I really liked it very
much: very easy to code, and, the entire library was developed using
MODCAL.  SPL seemed to be better at stack operations (somewhat faster),
but MODCAL provided so much more, that a small performance penalty was
no problem.  Unfortunately, the C folks won the battle, and, prior to my
leaving, most of the code was being developed with C.

I'm an avid fan of Pascal, and, having FreePascal definitely is a
blessing (www.freepascal.org).  I sure would like to get a good modula-2
(open-source) that runs on Win32.  So far, not too impressed with these
compilers.

By the way, a simple HelloWorld program (4 liner) in pascal creates an
.exe file that is about 21,614 bytes.  The same program (again 4 lines)
iin HLA is 6,144 bytes.

I'm studying HLA rather heavily these days.  It's the only assembler
that makes a lot of sense.  For all interested, please take a look.  I'm
sure you would be pleasantly surprised.  It's not your average assembler
that takes lots of development time.  It was written by Randal Hyde (the
guru of assembly language), which he still uses in teaching his
assembler course at the university.

Going back to MPE...

There is really too much effort to create MPE as a total package.  My
intention was to create "some" part of it that we all can use (CI would
be a good start).  And, one does not have to write the entire CI as a
start.  The code could be published as each command was added.  By
definition, this means that some of the intrinsics would be written to
be called by the CI commands.

So, version 1.0 might have just a few commands, 1.1 will add a couple
more, and so on.  At some point, we would have a "shell" that could be
used on say, Win32 (rather than dealing with all the .bat files).

I think this would be a good start.  The worst one could do is give all
the MPE folks a shell that they can take with them.

Granted, this would not be a "real" MPE, but it would be a start.

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