At 05:54 PM 10/1/02 -0500, you wrote:
<SNIP well stated evolution of processors discussion>
>All this to say, that even with a single CPU, the combination should be a
>lot faster than current MPE machines or even what they would be at the
>snail's pace of development exhibited by HP over the last decade.  So, even
>if you looked at the number of CPU's it would be irrelevant.  I sure hope we
>are not going to do some fancy crippling here.  :)
>
>Denys...

I agree with what you posted, the last line especially made me smile.  By
definition, emulated code IS performance crippled ;-)

I view the project being discussed on this list as not all that dissimilar
to the original migration that took place with MPE from its 16 bit CISC
hardware platforms to MPE/XL on the 32 bit RISC platforms.  If you will
indulge me, I would like to dream...

Using an approach similar to that HP originally took seems to me the right
way to address this migration.  Having a emulation (compatibility mode)
that takes existing MPE object code and translates it to appropriate Intel
x86 instructions would minimally allow the code to run on the Intel
platform (no trivial task to be sure).  Of course, this might imply double
overhead (kind of like double secret probation, but different) in that the
emulation may need to consider 16 bit MPE and 32 bit MPE/XL - MPE/IX code.

I would think the ultimate goal would be to allow for a NMi (Native Mode
Intel) object code compiler for the MPE code to allow the CM and NM MPE/nmf
(name your flavor) code to run at true full performance native environment
would be the ultimate goal - that and having compilers which might generate
NMi object code based on existing language source code for MPE/nmf would
also be a good thing.

Perhaps those looking at putting all this together might also look at
having several variations of an MPE "virtual machine" that code could
operate in.  For example, an MPE/CMVM could be optimized for older MPE 16
bit code, an MPE/NMVM might be optimized for 32 bit only code (one might
have to research to find out if the stubs are 16 bit for this one, don't
know if MPE/IX still uses these), an MPE/CNMVM mixed mode and the MPE/NMi
environment for native compiled Intel per above.  Really, all a loader
would have to do is determine which code is running and send it to the
appropriate VM for execution.  Heck, with a quad processing Intel based
box, perhaps one could even allocate a processor for each VM.

If the new architecture is (dare I say it) robust enough, perhaps it could
even be designed to load other OS architectures to run along side of the
MPE VMs.  Arguably, there might be some compromise to MPE's security
features in doing this, but it would be cool to directly address your batch
jobs from a Windows editor on the same machine (with respects to HP,
Edit/3000 is so 1970's).

I have no idea if this may be appropriate for the list (heck I don't know
if the above was all that appropriate), but it would be rather interesting
to know who we have here and what levels of experience is on this
list.  Perhaps the good folks at OpenMPE might entertain keeping a
discussion board for such a purpose.

If there actually is an interest in having such a place, I think I could
dredge up an old copy of WebBoard, an old server and an appropriate sub
domain for this purpose - if anyone is interested in my doing this, email
me off-list (to the [log in to unmask] address) and based upon interest
I shall go ahead an put something up as my small contribution to the
OpenMPE community.  On the other hand, if I am way off base, please accept
my apologies and I'll just go back to running my small Internet company.

Best,

Alan Maitland
[log in to unmask]
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/

Proud owner of 3 eBay purchased HP3000 systems (for which the former owners
finally announced they could not supply the proof of ownership docs)...
purchased roughly 2 months before HP announced discontinuation of the
HP3000 line.  Am I having fun or what?