Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated information on PDP timings

Browse source
This commit is contained in:
Jeff 2017-02-23 09:02:48 -08:00 • committed by Jeff Parsons
commit 0aa88da301
4 changed files with 34 additions and 53 deletions
Download patch file Download diff file Expand all files Collapse all files

25
modules/pdp10/lib/cpu.js
View file

@ -34,31 +34,6 @@ if (NODE) {
var MessagesPDP10 = require("./messages");
}
/*
* A word (or more) about PDP-11 speeds:
*
* After looking over the timings of PDP-11/70 instructions, nearly all of them appear
* to be multiples of 150ns. So that's what we'll consider a cycle. How many 150ns are
* in one second? Approximately 6666667. So by way of comparison to other PCjs machines,
* that makes the PDP-11 (or at least the PDP-11/70) look like a 6.67Mhz machine.
*
* I've started with the PDP-11/70, since that's what Paul Nankervis started with. When
* I go back and add support for earlier PDP-11 models (primarily by neutering functions
* that didn't exist), I will no doubt have to tweak some instruction cycle counts, too.
*
* Examples of operations that take 1 extra cycle (150ns): single and double operand byte
* instructions with an odd address (except MOV/MTPI/MTPD/JMP/JRS), ADD/SUB/BIC/BIS/MOVB/CMP/BIT
* instructions with src of R1-R7 and dst of R6-R7, RORB/ASRB with an odd address, and each
* shift of ASH/ASHC. As you can see, the rules are not simple.
*
* We're not simulating cache hardware, but our timings should be optimistic and assume 100%
* cache hits; for cache hits, each read cycle is 300ns. As for write cycles, they are always
* 750ns. My initial take on DEC's timings is that they are including the write time as part
* of the total EF (execute/fetch) time. So, for instructions that write to memory, it looks
* like we'll normally need to add 5 cycles (750/150) to the instruction's base time, but
* we'll need to keep an eye out for exceptions.
*/
/**
* @class CPUPDP10
* @unrestricted

12
modules/pdp10/lib/cpustate.js
View file

@ -92,6 +92,16 @@ class CPUStatePDP10 extends CPUPDP10 {
* constructor, along with a default speed (cycles per second) based on the specified (or default)
* CPU model number.
*
* Speeds are highly instruction-specific and are not broken down into cycles; DEC documents them
* as a number of microseconds, with two decimal places of accuracy. The simplest instructions
* execute in 1-3us, a number of others require 5-6us, and the most time-consuming take anywhere
* from 10us (MUL) to 17us (DIV). Of course, instructions that perform multiple indirect memory
* accesses take even longer.
*
* I think we'll just say that the original PDP-10 was roughly a 1Mhz machine, and pretend that all
* instructions completed in 1 or more multiples of a microsecond. I'm not sure that trying to be
* accurate to the nearest 1/100 of a microsecond would have much observable benefit.
*
* @param {Object} parmsCPU
*/
constructor(parmsCPU)
@ -102,7 +112,7 @@ class CPUStatePDP10 extends CPUPDP10 {
switch(model) {
case PDP10.MODEL_KA10:
default:
nCyclesDefault = 6666667;
nCyclesDefault = 1000000;
break;
}

25
modules/pdp11/lib/cpu.js
View file

@ -34,31 +34,6 @@ if (NODE) {
var MessagesPDP11 = require("./messages");
}
/*
* A word (or more) about PDP-11 speeds:
*
* After looking over the timings of PDP-11/70 instructions, nearly all of them appear
* to be multiples of 150ns. So that's what we'll consider a cycle. How many 150ns are
* in one second? Approximately 6666667. So by way of comparison to other PCjs machines,
* that makes the PDP-11 (or at least the PDP-11/70) look like a 6.67Mhz machine.
*
* I've started with the PDP-11/70, since that's what Paul Nankervis started with. When
* I go back and add support for earlier PDP-11 models (primarily by neutering functions
* that didn't exist), I will no doubt have to tweak some instruction cycle counts, too.
*
* Examples of operations that take 1 extra cycle (150ns): single and double operand byte
* instructions with an odd address (except MOV/MTPI/MTPD/JMP/JRS), ADD/SUB/BIC/BIS/MOVB/CMP/BIT
* instructions with src of R1-R7 and dst of R6-R7, RORB/ASRB with an odd address, and each
* shift of ASH/ASHC. As you can see, the rules are not simple.
*
* We're not simulating cache hardware, but our timings should be optimistic and assume 100%
* cache hits; for cache hits, each read cycle is 300ns. As for write cycles, they are always
* 750ns. My initial take on DEC's timings is that they are including the write time as part
* of the total EF (execute/fetch) time. So, for instructions that write to memory, it looks
* like we'll normally need to add 5 cycles (750/150) to the instruction's base time, but
* we'll need to keep an eye out for exceptions.
*/
class CPUPDP11 extends Component {
/**
* CPUPDP11(parmsCPU, nCyclesDefault)

25
modules/pdp11/lib/cpustate.js
View file

@ -88,8 +88,29 @@ class CPUStatePDP11 extends CPUPDP11 {
* addrReset: reset address (default is 0)
*
* This extends the CPU class and passes any remaining parmsCPU properties to the CPU class
* constructor, along with a default speed (cycles per second) based on the specified (or default)
* CPU model number.
* constructor, along with a default speed (cycles per second) based on the specified
* (or default) CPU model number.
*
* After looking over the timings of PDP-11/70 instructions, nearly all of them appear
* to be multiples of 150ns. So that's what we'll consider a cycle. How many 150ns are
* in one second? Approximately 6666667. So by way of comparison to other PCjs machines,
* that makes the PDP-11 (or at least the PDP-11/70) look like a 6.67Mhz machine.
*
* I've started with the PDP-11/70, since that's what Paul Nankervis started with. When
* I go back and add support for earlier PDP-11 models (primarily by neutering functions
* that didn't exist), I will no doubt have to tweak some instruction cycle counts, too.
*
* Examples of operations that take 1 extra cycle (150ns): single and double operand byte
* instructions with an odd address (except MOV/MTPI/MTPD/JMP/JRS), ADD/SUB/BIC/BIS/MOVB/CMP/BIT
* instructions with src of R1-R7 and dst of R6-R7, RORB/ASRB with an odd address, and each
* shift of ASH/ASHC. As you can see, the rules are not simple.
*
* We're not simulating cache hardware, but our timings should be optimistic and assume 100%
* cache hits; for cache hits, each read cycle is 300ns. As for write cycles, they are always
* 750ns. My initial take on DEC's timings is that they are including the write time as part
* of the total EF (execute/fetch) time. So, for instructions that write to memory, it looks
* like we'll normally need to add 5 cycles (750/150) to the instruction's base time, but
* we'll need to keep an eye out for exceptions.
*
* @param {Object} parmsCPU
*/