Timing of PDP-11 Instructions
bqt at update.uu.se
Thu Dec 1 04:47:48 CST 2005
On Wed, 30 Nov 2005 22:39:07 -0500 Allison <ajp166 at bellatlantic.net> wrote:
>>>Subject: Re: Timing of PDP-11 Instructions
>>> From: "Jerome H. Fine" <jhfinexgs2 at compsys.to>
>>> Date: Wed, 30 Nov 2005 21:57:37 -0500
>>> To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
>>>I am still not able to figure out why the FORTRAN 77
>>>subroutine has different timing when the destination
>>>address is moved from PAR0 to PAR1 under RT-11 under
>>>both E11 and a real PDP-11/73. Cache has been suggested,
>>>so I will attempt the calculation with a PDP-11/23
>>>which does not have any cache.
>Cache is half the answer. The other half is when you hit the bus
>on a cache miss two things have to happen. You have to do bus
>transactions which are very slow compared to cache and you have to
>refill the cache. IF there is any MMU action required
>(pagein/pageou) you add that overhead as well.
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
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.
>Remember the PDP11 is 16 bits. Any addressing outside ~28kwords
>is going to involve a MMU operation. That a lot of register
>access and it's costly(in time), more so if you need to move
>the Dmap in an I&D machine (11/73). The reason for that is those
>actions lie inside the core OS and require system calls to process.
>E11 is just being faithful to the core PDP11 so I'd expect similar
>if not exact same behavour. You didn't say RTll SJ or FB.
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
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
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
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
>Shame you can try that (in F77) on a VAX or PC wher 32bit address
>space is the rule. I'd expect much different behavour..
>Till your task is paged out. ;)
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 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
More information about the cctech