CIS = Commercial Instruction Set -- a set of additional instructions/op-codes for BCD and string manipulation; COBOL/DIBOL being the primary target
CISP = Commercial Instruction Set Processor -- the additional hardware that implements the CIS
- 11/44 has a two-module set (one HEX, one Quad) -- implementing what I believe operated as a full co-processor
- 11/74 apparently had a 4-module set -- presumably it could run as a co-processor
- 11/23 (F11) has a quad-ROM in one extra-wide 40-pin chip; no extra hardware, so just (lots of) microcode and thus no co-processing
The co-processing bit was that since operations could be run against character-strings or BCD-sequences it could take some time before one might complete; since that activity was using dedicated hardware (excepting memory access), in the meantime the CPU could be continue to be "productive" with the ALU/etc.
I don't think that the J11 had any CIS-support?
Good summary. However the classification as a 'co-processor' is not accurate. The CISP engines (both 11/44 and 11/74) operate much the same as the corresponding FP11 engines do on those machines, more as an extended datapath and microengine. Once a CIS instruction is decoded the main CPU passes control over to the CISP microengine, and it assumes control from then on. The CISP drives a microaddress over to the main CPU to force it to do specific pre-coded microops. Both the 11/44 and 11/74 CISPs did not do any operand decoding or memory accesses directly, but forced the main CPU to do them for it. So in effect from the user code point of view the CIS instruction would run to completion before allowing the main CPU to continue.
CIS instructions could take some time to execute (ie, like a MOVC with a 64KB string length that shifted all 64KB of data space virtual memory up one byte). This could take tens of milliseconds to execute the one instruction.
The impact could be severe on interrupt latency, so the CISP instructions were implemented with the capability of suspend and resume. CISP instructions could checkpoint themselves by pushing up to 64 words of state on the stack, and setting a bit in the PSW (a previously unused bit) to indicate the instruction was suspended.
So for very long instructions the CISP microcode might check every 100 usec or so for an interrupt pending, and if so it would cause itself to suspend and allow the interrupt to be serviced. As part of the suspension it would push any state on the stack it wanted to save, set the PSW suspend bit, and backup the PC to point at the CIS instruction. So when the interrupt service completed and the CIS instruction restarted it would look at the PSW bit to see if it was a restart vs a new execution, and if a restart pop the saved info off the stack and resume the instruction where it left off.
Needless to say this added an additional level of complexity (and regression testing!) to the microcode implementation and debug/validation. The DEC diagnostic written for CIS (ZKEEA0) has explicit support for the KW11P programmable (or line) clock to fire off interrupts as fast as possible to cause CIS instructions to be restarted ad naseum.
When implementing the CIS microcode we made decisions on each instruction as to how the interrupt check/restart would be handled:
(1) for very short instructions (ie, load descriptors) we did not check for interrupts midstream, and never did a restart. The only interrupt check was at the end of the instruction, same as for any regular PDP-11 instruction.
(2) do an instruction restart instead of resume. Set the resume bit in the PSW, but don't push any intermediate state on the stack. If an interrupt comes in just throw away any current instruction progress and restart the instruction from scratch on the next decode. This was used very rarely as with a high enough interrupt rate no forward progress would be made in the CIS instruction execution, causing the system to essentially stall until the interrupt rate was reduced. Off hand I don't recall which (if any) CIS instructions used this choice, it was certainly the least optimal choice of last resort.
(3) do a full instruction checkpoint and resume. Set the resume bit, push up to 64w of state on the stack. Design the microcode to always make some forward progress before the next interrupt check. So even with a very high interrupt rate the instruction will complete in a finite, predictable amount of time. Most instructions just needed to use the general registers (which held the operand descriptors) and the resume bit to restart, or maybe a word or two of state on the stack. However, a few exceptions (like MULP and DIVP) required saving a full 64w of intermediate state to resume.
Now back to your regular programming ... and thanks to John for the details on the 11/730 console subsystem.
Don