🚀 go-pugleaf

In article <HOLMER.92Dec18174207@rose.eecs.nwu.edu> holmer@eecs.nwu.edu (Bruce Holmer) writes:
>
>Does someone have a table of instruction cycle
>counts for a high-end PDP-8?  I'd need to know
>about how many cycles the different addressing
>modes require and how to calculate the cycle
>count for the OPR instructions.
>
>Thanks,
>--Bruce


It's interesting timing that you ask for benchmarks as there is another
simulator soon to make the light of day.  This one is for a *real* PDP-8
meaning it supports peripherals including disks.  It's specifically for
80286 and up machines with HD diskette drives.  The author cannot currently
post to usenet but can e-mail, etc.  He wants representative code so that
he can determine the ratio of PDP-8 to simulator performance using a wide
variety of programs, etc.

Not counting the 6120 cycle time, which is somewhat erratic depending on
which instructions specifically we call out, it's best to stick to the 8/e
processor with static memory for timing.  This is the most common configuration
anyway.

All OPR instructions are 1.2 microseconds each regardless of group or outcome
of any test.

All internal IOT instructions are also 1.2 microseconds unless "stretched"
by a peripheral using the NOT LAST TRANSFER line on the OMNIBUS.  If the
cycle is external, and there actually is a KA8E installed, the cycle will
be stretched my an amount determined by the KA8E, and can be adjusted to
many microseconds to accomodate very long (over 50 foot) external positive
and/or negative busses.

All other instructions are two-cycle and thus take 2.6 microsends, or if
indirect are 3.8 microseconds unless auto-indexed in which case make that
4.0 microseconds.

If EAE is present, various group 3 instructions are implemented that take
a varying amount of time such as long shifts which are shift-count dependent
for total execution time, and there are many different timings for each of the
different instructions.  In some cases, instruction timing can also be affected
by auto-indexing operations, such as when the EAE diagnostic places a
MUY instruction into location 00007 so that the operand pointer is in location
00010 thus causing an auto-index as a "feature".

All of these timings assume no memory collisions such as occur when the
MOS memory cards (DRAM) are used, or if DMA is occuring simultaneously.  There
is no pipelining used, although the architecture would easily allow it.  There
is some instruction prefix optimization in the 6120 implementation, thus
instruction times widely vary with respect to the 8/e.  Some are marginally
faster, yet others are quite a bit slower.

By using a short buss, it is possible to "tweak" the CPU timing to get speeds
about 20% better than this accurate nominal speed (crystal-controlled).  
CESI is/was marketing a replacement VLSI processor that was/is quite a bit
faster, etc.

cjl

From article <HOLMER.92Dec18174207@rose.eecs.nwu.edu>, by holmer@eecs.nwu.edu (Bruce Holmer):
> 
> Does someone have a table of instruction cycle
> counts for a high-end PDP-8?  I'd need to know
> about how many cycles the different addressing
> modes require and how to calculate the cycle
> count for the OPR instructions.

There were two different memory cycle times on the PDP-8/E (that was probably
the highest of the high-end PDP-8 machines):  1200ns and 1400ns.

An instruction fetch was one short cycle.
Indirect addressing cost one short cycle, unless it was through an
  autoindex register, in which case you pay for a long cycle.
Operand fetch for AND and TAD cost one long cycle.
Operand fetch/increment/store for ISZ cost one long cycle.
Operand store for DCA and JMS cost one long cycle.
JMP cost nothing other than the instruction fetch and indirect cycles.
IOT to omnibus peripherals cost nothing beyond the instruction fetch cycle.
OPR for non EAE instructions cost nothing beyond the instruction fetch cycle.

These figures are for the standard PDP-8 memory, and must be adjusted if
you want to talk about the various strange things that happened when they
abandoned core, particularly, it should be noted that the ROM technology
of the mid 1970's was a bit on the slow side.

				Doug Jones
				jones@cs.uiowa.edu