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.