Access to IOPAGE Registers using PDP-11 Opearting Systems
Jerome H. Fine
jhfinedp3k at compsys.to
Thu Nov 22 20:06:19 CST 2007
>Johnny Billquist wrote:
>>ons 2007-11-21 klockan 12:00 -0600 skrev "John A. Dundas III"
>dundas at caltech.edu>:
>>I can speak for RSTS with some authority, RSX with somewhat less authority.
>>At 9:17 PM -0500 11/20/07, Jerome H. Fine wrote:
>>>I doubt that RSX-11 or RSTS/E allow a user access to the IOPAGE
>>>even via PREVIOUS DATA space. Can anyone confirm this assumption?
>>Address space in the I/O page for RSTS jobs (processes) was not
>>directly available. The APRs are always controlled by the OS. It
>>MIGHT be possible for a privileged job to use PEEK/POKE SYS calls to
>>access the I/O page in the way you suggest but it would be
>I thought RSTS/E had some way of remapping the address space as well.
>Can't you remap parts of your memory to some shared region, for example?
Jerome Fine replies:
I am replying to Johnny's response, but I had also read the other
replies as well.
Thank you all for your help.
The first point is that using a PEEK/POKE SYSTEM (EMT? - RT-11 has such
is so high in overhead that it becomes almost useless. In fact, the key
point about the
use of the EMEM.DLL under RT-11 is the efficiency. While it is possible
normal "emulated PDP-11" memory (using E11 on a 750 MHz Pentium III) in
0.3 micro-seconds, it takes about 1.2 micro-seconds to reference an
in some sort of way - including the PSW or the EMEM.DLL values or about
as long. Since this is a huge improvement over using a PEEK/POKE, it is
giving up 8192 bytes of address space to a dedicated APR (of the IOPAGE)
On the other hand, with RT-11, it is possible and easy to set the
space in the PSW to KERNEL even when VBGEXE is used - more to the point,
it is actually unnecessary since that is the default for a so-called
privileged job (which
all programs are by default). This allows the instruction:
Mov @#BaseReg,R0 ;Get the current value from PC memory
to be replaced by:
MTPD @#BaseReg ;Get the current value
Mov (SP)+,R0 ; from PC memory
with almost the same time for execution. It also avoids losing that
8192 bytes for APR7
being available just for the IOPAGE registers.
Obviously, a SYSTEM request avoids all of the problems at a heavy cost
estimated at between 50 and 500 times the above two examples.
That was sort of what I was thinking about when I asked if there was an
(only a few instructions)" to access an IOPAGE register.
By the way, a first version of a set of FORTRAN IV/77 interface
available for use under RT-11 and any other program that has access to
registers either in CURRENT DATA space or PREVIOUS DATA space.
>>RSX had a bit more flexibility (opportunity) in this regard. I
>>believe you can set up a CRAW$ (create address window) directive in
>>either Macro or Fortran to achieve the desired result.
>Yes with reservation. CRAW$ (create address window) is as a part of
>doing dynamic remapping of your address space.
>However, CRAW$ always required a named memory partition. You cannot
>create an address window to an arbitrary memory address.
>Also, the memory partitions have protections and ownership associated
>On most systems, CRAW$ cannot get you access to the I/O page, simply
>because normally you don't have an address space and a partition
>associated with the I/O page.
>But if such a partition is created, then CRAW$, in combination with MAP$
>would allow you to access the I/O page.
>The same thing can also be achieved even without CRAW$/MAP$, since you
>can specify mapping that your task should have already at task build
>time, with the COMMON and RESCOM options to TKB.
This seems to be the answer if it is allowed. Obviously it does require
that 8192 bytes the have APR7 mapped to user space.
There is also another option with E11 that I will make use of when I
with the HD(X).SYS device driver for RT-11. It turns out that if the
being accessed sequentially, the average time to reference a single 16
in the file under:
MOUNT HD: FOOBAR.DSK
is actually less than the time to get/store a single value under
EMEM.DLL when as
few as 8 blocks (2048 words at a time) are being referenced.
up a small 4096 byte buffer and the associated code to handle to calls
to the HD:
device driver (all standard calls to .ReadF and .WritF in RT-11) is
efficient since after the values are in the buffer inside the program,
the values can
be referenced and modified at "emulated PDP-11" memory speeds.
Of course, the above solution for sequential references does not work
references are random or when references are at regular but very large
(thousands and even millions of successive values). For this latter
may be possible to modify EMEM.DLL so that a single reference to the IOPAGE
register modifies all of the specified values (over a range of up to
many billions of
Of course, the result would no longer really be a PDP-11 except for the
code which would still be 99% of the required code since the EMEM.DLL
are really quite trivial, yet consume 99% of the time to execute. In
does not appreciate what I refer to, it is back to my other addiction -
prime numbers. I realize that I should probably switch to native
but is seems more of a challenge and much more fun to run as if a PDP-11
used with a few GB of memory somewhere out there that can be easily
as if there is a very fast additional CPU similar to those that used to
be available for
special math applications - anyone remember SKYMNK for FFTs?
More information about the cctalk