Timing of PDP-11 Instructions

[Jerome H. Fine]

 >Allison wrote:

>>Subject: Re: Timing of PDP-11 Instruction
>>
>>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.
>
>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.
>  
>
Jerome Fine replies:

Here is an update on the timing problem.  I just finished
attempting to write a test program to reproduce the problem.

Earlier, I had discovered a program BUG which I initially
though had created the conditions which caused the situation
with respect to the PAR0 / PAR1 timing problem to occur.

Well, I just discovered a SECOND program BUG 2 in the same
loop (just two lines above).  I used "Cmp R1, at 4(R5)" and
it should have been "Cmp R1,4(R5)" instead.  I don't think
it is worth any additional effort at this point based on
just 10 minutes of attempting to understand the overall
interaction.  However, I am reasonably confident that the
timing problem had NOTHING to do with a PAR0 / PAR1 address,
but rather just the arithmetic which resulted from an
"interesting" set of conflicts due to both bugs.

Over the past 45 years, I thought I had found a hardware
problem 3 or 4 times, but the difficulty was always a
really difficult to find (translation - dumb) software
bug.  Well, I did it again.  I am confident the timing
problem was purely the result of two conflicting bugs
in the software.  Mea culpa!

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.