HP3000-L Archives

December 2001, Week 2

HP3000-L@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:
Dennis Walker <[log in to unmask]>
Reply To:
Dennis Walker <[log in to unmask]>
Date:
Thu, 13 Dec 2001 12:31:47 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (113 lines)
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.

And because most applications on the 3000 spend 90 or more percent of their
time in system calls (intrinsics), emulated program would have good
performance.   Looking at CI.PUB.SYS's externals below, the CI could
probably be run emulated at first.  That would go for all the compilers, and
most likely VPLUS, because all of these are really user space programs that
call the intrinsics (along with some libraries in the system xl ) to get
their job done.  The system xl would have the intrinsic libraries replaced
with stubs to the native layer, and everything else could be emulated.

This frees the implementers to do what ever the need to map mpe's io on to
linux.   The transaction manager and anything else that is transparent to
the user need not be implemented exactly as MPE does now.

As for going the other way, having linux native programs accessing MPE files
like POSIX  does now; with MPE mapped onto linux native file system, small
modifications to libc.... the equivalent of the system XL could be added to
pass io back through the mpe intrisic layer to do the record to byte stream
translation like POSIX does now.

This record oriented to byte oriented translation is really what happens in
MPE now, file access is really built on top of memory management, files are
really just memory space with MPE intrinsics proving the user interface,
which you can bypass by using mpe own mapped file functions.

CI.PUB.SYS Sym Name
----
$START$
PROGRAM
_start
check_parm_info
ci_cmd_io
flush_job
handle_logon_cmds
handle_recover
initialize_break
initialize_cienv
main_ci
print_ci_banner
receivebreak
verify_parm
$RECOVER_END
$RECOVER_START
$START$
$UNWIND_END
$UNWIND_START
10237OB
PROGRAM
_start
check_parm_info
ci_cmd_io
flush_job
handle_logon_cmds
handle_recover
initialize_break
initialize_cienv
main_ci
print_ci_banner
receivebreak
verify_parm
M$1
FCONTROL
FWRITE
P_GET_INFO
P_GET_PARM
P_INIT_ARGS
P_INIT_HEAP
P_SET_COMPACTION
P_TERMINATE
SETJCW
U_EXIT
U_INIT_TRAPS
U_get_escapecode
U_nonlocal_escape
cerror
ci_brk_finish
ci_cleanup
ci_redirect_to_terminal
cior_unredirect_io
ciprinterr
configure_break
create_redo_stack
exec_usercmd
execute_delayed_interrupt
genmsg
get_ccb_ptr
get_logon_cmd
get_misc_config_info
get_readcmd_mode
init_ccb
jsinfo
jsset
print_welcome_msg
probe_close_fd
readcmd
set_ptr_ccbhdr
system_abort
trap_handler
udc_ci_setup
unexpected_escape_abort
xeqcommand

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

ATOM RSS1 RSS2