8 Feb
2022
8 Feb
'22
9:34 a.m.
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: 08 February 2022 01:04
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: Weird microcode bug in the 11/60 CPU
On 2022-02-08 00:15, Thomas DeBellis wrote:
I am told by a guy who used to lecture at Manchester University that when they were
developing the MU5 experimental computer, they found that in general about one in six
instructions was a jump/branch.
This meant that an instruction pipeline longer than 6 provided little performance
improvements.
... so they developed a "heuristic pipeline" with content addressable memory.
Whenever a jump/branch instruction is executed, an entry is made in content addressable
memory showing the location of the jump and the location of the next instruction executed.
(this may of course simply be the next instruction). When the pipe-line building logic
fetches a "jump" instruction it checks the content addressable memory to see if
we have executed this jump recently.
If so we then fill the pipeline from where the code branched to last time. We may not be
right, in which case we are no worse off, but if we do get it right, and as a lot of code
consists of loops, then we have the code we need in the pipeline and performance is
improved.
Sadly all the papers I can find on this are behind expensive paywalls. E.g.
https://dl.acm.org/doi/10.1145/359327.359333
Dave
I remember taking a course in systems
architecture from an IBM'er when
he pointed out that, based on their measurements and sampling,
arithmetic wasn't as big a portion of the instruction mix as might
commonly be thought. He said, "Computers don't add. What computers do
is branch." (IBM lingo for a jump or a change of PC). It was one of
those eye opening moments.
Well, branches are definitely important. But computers do a lot of just
moving data around as well. Which sometimes is one of those times when
the condition codes helps. If you want to move until some condition, you
might be lucky that this condition can be easily detected without any extra
instructions. Such as moving something until you hit a NUL... :-)
So, Yes, you
are going to have a bunch a jumps, it's really about how
they get hit.
Yup.
I found doing a compare and conditional jump
nice, but perhaps that's
because this is how the x86 does unsigned arithmetic, which the 10
doesn't really have.
On the PDP-11 condition codes for both signed and unsigned conditions are
generated all the time, so it becomes a question of just picking the right type
of conditional branch.
I think the only time skips ever get confusing
for me is when you want
to transfer execution based on a bunch of bits all being on. You can
test for them all being off (TxnE), but the corresponding test (TxnN)
skips if *any* of them are on. So that means you have to complement
the bits (TRC, say) then test them for being off while complementing
them back again.
Yeah. That's always one of those annoying things. Another way is to mask out
the interesting bits and compare to the expected value. But it's additional
instructions anyway. The problem exists in the same way on the PDP-11.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se