On Wed, 30 Nov 2005 22:39:07 -0500 Allison <ajp166 at bellatlantic.net> wrote: <cctalk at classiccmp.org> Nonsense! No PDP-11 operating system have demand paging and page faults. It could be done, but noone is doing it. So you just have the memory access instead of a cache hit. But memory access is just so much slower. And the bus transaction is a part of that memory access. Oh, and the cache is working on *physical* address, not virtual. (You would get serious problems if you used the virtual address for the cache.) So, before you can even figure out if the data is in the cache or not, the MMU must do the address translation. This also seems like a silly statement. From a program point of view, you cannot access anything outside 32Kword. Never. Like you say: the PDP-11 is a 16-bit architecture. The MMU is always involved in mapping your 16-bit address into the 22-bit address space The memory is sitting on a 22-bit address space, so you *must* generate a 22-bit physical address. With the MMU disabled, the MMU have a wired mapping to the physical address space, while if the MMU is enabled, all addressing goes through the proper MMU PAR. This don't incur any timing overhead at all. The time for passing through the MMU is always present, and you cannot do anything about it, nor detect it. And as I said above, the MMU must first translate the virtual address into a physical address before the cache can take a shot at it. (Incidentally, the hardwired addressing used if the MMU is disabled, is to map the low 28 Kword of virtual space into the low 28 Kword of physical space, but to map the last 4 Kword of virtual space into the last 4 Kword of physical space, which is the I/O page. If you switch to 18-bit addressing, the MMU registers gets involved, but only the low 12 bits of the PAF are used, and of course in 22-bit mode all 16 bits of the PAF is used.) The MMU PAR is set up before the program can execute, and there is no more overhead in accessing something through the D PARs than the I PARs. You could possibly argue that the OS will need more time to fill in the PARs if you have split I/D space, since that means you need to fill in more registers. The PDP-11 is not like more modern virtual address machines, where you have a TLB, which is a cache for the MMU registers, and which is filled in dynamically as the program proceeds. The PDP-11 have a very static register set for the MMU, and those registers are already inside the MMU. And the mapping is rather static as well. Heck, you only have a total of 48 PARs at maximum to fill in. And that's only if you use all eight PARs for both I and D space, and for kernel, supervisor and user mode. No, Jeromes "problem" really can only be attributed to cache conflicts. It's not really a PAR0 vs. PAR1 problem, but a problem of both program and data hitting the same cache lines. With 8K cache, you have 13 address bits which select the cache line (well, since the cache is really 16 bits wide it's actually 12 address bits, A1-A12). A13-A21 is used as the cache tag. Any data hitting the same cache line is matched on the cache tag, and if the tag don't match, the cache is reloaded from memory. Otherwise data is served from the cache directly. So, if Jeromes program is in continous memory (which I assume it is, since RT-11 really don't do much fancy work with the MMU), PAR1 comes directly after PAR0 in physical memory, which means that the same relative address within each PAR will hit the same cache line. E11 will not have this problem, since E11 don't really implement the PDP-11 cache. No point in doing that. However, E11 is running on a i386, which happens to have exactly the same possible problem. All machines with cache will display the same behaviour. If you are smart, you can write a program that will tell you exactly how much cache you have, how many levels there are, the TLB size (if you have one), the associativeness of all caches, and also the timing of it all. And all of this is done by probing the same thing Jerome just discovered. :-) I have such a program somewhere around here, but it's really something that most people working with these things at a low level already should know about. It would be different, of course, in the sense that that program would have different cache sizes, different associativeness of the cache, would also have a virtual demand page system with a TLB, and a larger natural word size, which would change the requirements of the program. But we could easily create a similar effect on any machine. That is, the speed of the program would be affected by where the data was placed. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.10/188 - Release Date: 2005-11-29