Jerome Fine replies: Which means that using a system call is useful only during initialization. For example, RT-11 allows the user to .Peek/.Poke the PSW which I agree would be VERY unreasonable under RSX-11 and RSTS/E which depend on the KERNEL code maintaining complete control. However, under RT-11, the VBGEXE program sets the PREVIOUS DATA space to user mode for reasons which I do not understand. Fortunately, it is possible to use the .Poke system call to set the PREVIOUS DATA space back to KERNEL which is what the RT-11 setting is prior to using VBGEXE. When the PREVIOUS DATA space is KERNEL, it is possible to use the 2 instruction example given below. So a system call to .Poke during initialization is entirely acceptable. See my previous response with respect to RT-11 and my agreement that under RSX-11 and RSTS/E, the PSW must NEVER be modified by a user program or a .Poke requested by a user program. That is helpful information. There might be times when APR7 should not be used. Also VERY helpful. However, if so, then would there be any reason why APR7 could not be mapped to user memory in the normal manner so that the user program has a full 65536 bytes of address space, but then the PREVIOUS DATA space is mapped to KERNEL providing the user with complete access to the IOPAGE registers via that 2 instruction example that I gave at the beginning? I can't see that there would be any greater loss of security since being able to change the IOPAGE registers either directly or indirectly is just as damaging! Please comment? But unnecessary if privileged jobs already have access to the IOPAGE. Please comment? Actually, under E11, it is almost identical in principle to the VM: device driver which accesses "emulated normal PDP-11 extended memory". The E11 command: MOUNT HD: RAM:/SIZE:number-of-blocks makes HD: into a Virtual Memory device which directly uses PC memory. However, the average transfer rate per word for even a few blocks (or a few thousand words) from/into emulated user memory is a small fraction of a normal memory access time. In addition, if an operating system caches the blocks in a file, the same speed is achieved. It is just a bit more complicated since the memory address can be anywhere in the 4 MB of emulated PDP-11 memory. So 22 bit address is required - which can be determined during initialization. The even better aspect is that the code (only about a dozen instructions which set up the 6 IOPAGE registers) can be in user space which avoids the overhead of a system call. And if you don't think that amounts to much, my benchmarks show that the transfer speeds with just 8 blocks (2048 words or 4096 bytes) take about half the time as a normal system call. Fewer blocks are even more efficient vs system calls. For a demonstration program to sieve up to 10**12, I can use normal PDP-11 memory for the work area of around 30 KB. The 2 arrays which will be used sequentially will require 78,498 elements each that are 32 bits or 4 bytes each - a total of less than a MB, but since they are used sequentially, can be easily read / written in groups of 2048 words or 8 blocks each. For those not familiar with sieving for primes, a very large memory is used! The problem is that sieving requires the storage of large memory used both sequentially and what seems like randomly. One array is used to store the primes being used. A second array is used to store the next location to be used in the work area for that prime. The work area is normally as large as possible and is accessed at intervals equal to the current prime being processed. These days, a sieve program up to a billion (10**9) is considered trivial. Most individuals who are serious consider any range under a trillion (10**12) to be in the nature of a toy. However, since the number of primes up to a trillion - described as pi(10**12) = 37,607,912,018 - requires more than 16 bits per element for the second array, just the storage of the second array of at least 78,498 elements is over 1/4 MB. And since pi(10**9) = 50,847,534 which is the number of elements in the second array required to sieve up to pi(10**18) = 24,739,954,287,740,860 for which 30 bits per element is just sufficient, the second array then requires over 200 megabytes. Of course, these memory sizes are no longer even very large for a current Pentium III system (I have a Pentium III with 768 MB of memory) and with a Pentium 4, they are only a small aspect of the problem. However, for the PDP-11, they are obviously impossible. Thus my interest in using E11 and the features that I have described. Note that pi(10**22) is considered to be known and pi (10**23) is likely known, having been recently found this year. pi(10**24) has still not been published, but will likely be known in the next year or two when faster algorithms are found or faster CPUs are used. Sieve programs were not used to find these values. Sincerely yours, Jerome Fine -- If you attempted to send a reply and the original e-mail address has been discontinued due a high volume of junk e-mail, then the semi-permanent e-mail address can be obtained by replacing the four characters preceding the 'at' with the four digits of the current year.