Access to IOPAGE Registers using PDP-11 Opearting Systems

Johnny Billquist bqt at
Sun Nov 25 07:07:37 CST 2007

"Jerome H. Fine" <jhfinedp3k at> skrev:

>  >Johnny Billquist wrote:
>>> ons 2007-11-21 klockan 12:00 -0600 skrev "John A. Dundas III"
>> dundas at>:
>>> Jerome,
>>> 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 
>>> particularly difficult.
>> 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 
> a call)
> 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 
> to access
> normal "emulated PDP-11" memory (using E11 on a 750 MHz Pentium III) in 
> about
> 0.3 micro-seconds, it takes about 1.2 micro-seconds to reference an 
> IOPAGE address
> in some sort of way - including the PSW or the EMEM.DLL values or about 
> 4 times
> as long.  Since this is a huge improvement over using a PEEK/POKE, it is 
> even worth
> giving up 8192 bytes of address space to a dedicated APR (of the IOPAGE) 
> for that
> purpose.

True. From an efficiency point of view, using system calls to read/write memory 
is very inefficient.

> 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.

That's not possible with OSes that maintain any kind of protection between 
processes, along with virtual memory.
The PSW as such, is not possible to manipulate. If you could, you can also 
change your mode to kernel even though it's currently something else.
Actually, you must be in kernel mode in order to modify the PSW with any other 
instructions than SEx and CLx.

> Obviously, a SYSTEM request avoids all of the problems at a heavy cost 
> in overhead
> 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 
> "fast method
> (only a few instructions)" to access an IOPAGE register.

Well, in RSX, you have a rather high overhead to set up the mappping to the I/O 
page, unless it's already mapped in when the task starts. But from there on, 
there is no overhead at all. It's located somewhere in your 16-bit address 
space. (Note that you really don't have to map the I/O page at APR7 in RSX. You 
can get it mapped anywhere if you use the CRAW$/MAP$ or TKB options.)

However, with normal privileged programs, the I/O page is always present at APR7 
even if you don't do anything.

>>> 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
>> with them.
>> 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 
> giving up
> 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 
> have finished
> with the HD(X).SYS device driver for RT-11.  It turns out that if the 
> memory is
> being accessed sequentially, the average time to reference a single 16 
> bit value
> in the file under:
> 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.  
> Consequently, setting
> 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 
> actually more
> 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.

You mean that using a device driver, and a device that can access the "normal" 
memory instead is better. Well, I'm not surprised. What this essentially turns 
into, is that you're emulating DMA.

> Of course, the above solution for sequential references does not work 
> when the
> references are random or when references are at regular but very large 
> intervals
> (thousands and even millions of  successive values).  For this latter 
> situation, it
> 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
> values).

Can't comment much, since I don't know exactly what you're trying to do.
But speedwise, if you really want something to act like fast disk, writing 
something that behaves like proper DMA is the best.
You give the device a memory address, a length, and a destination address on the 
device, and let it process the data as fast as it can, without involving the 
PDP-11 after that point.

> Of course, the result would no longer really be a PDP-11 except for the 
> controlling
> code which would still be 99% of the required code since the EMEM.DLL 
> changes
> are really quite trivial, yet consume 99% of the time to execute.  In 
> case anyone
> does not appreciate what I refer to, it is back to my other addiction - 
> sieving for
> prime numbers.  I realize that I should probably switch to native 
> Pentium code,
> but is seems more of a challenge and much more fun to run as if a PDP-11 
> is being
> used with a few GB of memory somewhere out there that can be easily 
> fiddled with
> 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?

Hmm, are you just creating a sieve for primes? Ok, then you need large memory 
Several ways of doing that. For your specific needs, a simple device in the 
I/O-page with a command register, an address register and a data register would 
probably be just about the best.


Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

More information about the cctalk mailing list