the multi-user program is a virtual machine
implementation
and the programs running on the machine have resources
like variables, arrays, files, and databases
Python variables? Python arrays (lists? tuples?)? Or some other sort of
"variables" and "arrays" that exist outside of Python?
You _really_ need to describe your execution environment ;)
http://bitsavers.informatik.uni-stuttgart.de/pdf/burroughs/B6500_6700/1035441_B6500_B7500_Stack_Mechanism_1968.pdf
The linked paper By Erv Hauck and Ben Dent describes what our ancestor
machine looked like in 1968, and is about the most recent documentation
commonly available on the web. Its been a few years since then, and the
machine has changed a little over time, but the basics of the word format
and stack mechanism and program structure are basically unchanged.
Since the machine is no longer represented by hardware, but instead by an
emulator running on Windows, we have some additional capabilities. For
instance, instead of writing a Python interpreter that will run inside the
virtual machine structure (effectively being a normal B6500 program, in
terms of the referenced document) I can use a Python interpreter (CPython)
that is an existing DLL running in the WIndows environment, and do a
procedure call from my B6500 environment into the Python environment.
Effectively this is a call from one stack-based procedure using one bytecode
to another stack-based procedure using a different bytecode. The interpreter
for the B6500 bytecode will realize what it is calling, fabricate an
appropriate call into CPython (possibly switching to a different thread if
that is necessary) and then let the Python code do its thing. Eventually the
procedure call will (probably) return, and the B6500 code will resume
execution. Basically there is a fence where we swich between interpreters on
a procedure call or return boundary.
The Python code is running as (I hope) a native Windows DLL, so should be
able to access any existing Python libraries that exist on the WIndows
machine. Obviously this Python code will be using Windows-shaped data
objects like integers, floats, and strings.
The B6500 code also has integers, floats, doubles, and strings, but they all
look different from what Windows data looks like. Since Python accesses
things as objects and objects have accessor methods, I am reasonably sure I
can either subclass existing Python objects to access B6500 data, or simply
make new objects to access that data. Thus the Python code, even though it
is running in its own interpreter, will be able to access resources within
the virtual machine environment.
Does that help? I can expound more if needed, but I don't want to bloat the
newsgroup with irrelevent stuff.
I don't think my main concern here is being able to call the CPython
interpreter routines, but instead it is to be able to provide separate
sandboxes for the various programs ("stacks", in B6500 terminology) that
might have their own Python sessions or programs.
One possible scenario is a B6500 user, sitting at a terminal, and typing
"run python". That should get him a copyright notice and a >>> prompt, and
he should be able to carry on just as though he was sitting at a Windows
command line. The guy at the terminal in the next office should be able to
be doing the same thing at the same time.
Loren
--
https://mail.python.org/mailman/listinfo/python-list
