25 Nov
2007
25 Nov
'07
8:07 a.m.
"Jerome H. Fine" <jhfinedp3k at compsys.to> skrev:
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.
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.
Correct.
Johnny Billquist wrote:
ons
2007-11-21 klockan 12:00 -0600 skrev "John A. Dundas III"
dundas at
caltech.edu>:
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 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?
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.
On the other hand, with RT-11, it is possible and easy
to set the
PREVIOUS DATA
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.
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:
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.
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
somehow.
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol