Yes this is exactly what the emulator should do, just like the old classic
sl is still here with the CM to Native stubs bridging  to native mode
implementations where those routines that were replaced. All this mapping
done and load time.

And it is what the aries one does for HPUX.  If this code could be migrated,
and made to read and use MPE object format we would be a long way to the
goal.

The good news is for most user binaries just replacing the intrinsics would
be suffient, but for some of the other hp & vendor supplied programs that
use AIF's and other kernel specific library calls, those calls will need to
be replaced.   And as you pointed out not all of these routines need
replaced, only kernel and hardware specific parts, and emulate the rest.
Just like the CM to NM transition went, more thing move to NM as time goes
on.

So a beginnig solution would be again rewriting the intrinisc and image.
Image because it is tightly coupled to the kernel using the transaction
manager, and other kernel supplied facilities that aren't used by any other
finished user applications directly. (This would include some replacement
for TPI interfaces).  And it would be better to make the new image use unix
native kernal facilities, maybe even build upon the hpeloquence code base.

Vplus could probably be mostly emulated once the intrinsics are done.  With
that many applications could run.

Initially the biggest problem for users applications is the system commands
that are called.  This requires some command interpreter functionallity,
which has been pointed out is a little tougher given the way the command
interpreter works.  But not impossible, and once studied fully a minimal set
NL replacement / Emulation could be done.

"Mark Wonsil" <[log in to unmask]> wrote in message
news:9vde2101ver@enews3.newsguy.com...
> Dennis writes:
> >The main emulation scheme that might work on linux, would be to rewrite
the
> >whole intrinsic layer including image, natively on linux.  This gives a
> >mpe-api directly for new applications, and with an emulation layer, user
> >binaries, and many other user space subsystems would work.  Luckily the
> >intrinsic layer is relatively small and well defined. And by replacing
the
> >intrinsic the emulater does not have to deal at all with real io so there
> is
> >no emulation of current hardware interfaces, just user space stuff, and
> >shared library access stuff.
>
> I was reading the slides that Wirt mentioned earlier about the HP-UX
> emulation for Itanium at:
>
> http://www.intel.com/design/itanium/tranhp/sld001.htm
>
> One of the slides mentions the importance of the object loader.  This is
the
> software that is responsible for resolving run-time libraries and
executing
> objects.  If I am correct, and I am sure to be corrected if not, you can
do
> some clever things in this area.  It would be possible to rewrite
libraries
> one at a time so the emulator actually calls native routines instead of
the
> emulated ones.  One can incrementally improve the speed of the emulation
as
> each library is converted to a native format.  You will still need the
shell
> to give you file equations, JCW's, system vars, etc. but I think this line
> of thinking is looking more and more promising as a long term solution (>
> 2006).
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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