Page Numbers: Yes X: 527 Y: -.5" First Page: 10
Heading:
Dorado Hardware ManualProcessor Section14 September 1981
Processor Section
The processor section implements most registers accessible to the programmer and decodes all instruction fields except JCN. The FF field of the instruction is also decoded by the control, memory, and IFU sections.
Read this chapter with Figure 1 in front of you.
The processor section contains the Q, ShC, Cnt, StkP, and MemBX registers, the T, RBase, MemBase, and TIOA task-specific registers, and the ALUFM, RM, and STK memories. It contains the arithmetic and logic unit (ALU) and the shifter.
The processor communicates with the control, memory, and IFU sections via B; with io devices via the IOB bus. It exports MemBase and Mar to the memory system for addressing, IOA to devices for io addressing, and branch conditions to the control section. It imports Md from the memory system and Id from the IFU.
RM and STK Memories, RBase and StkP Registers
RM ("Register Memory," sometimes called "R") is the memory most easily available to microprograms; it stores 256 words x 16 data bits with odd parity on each byte of data. RM is read at t0 and latched at t1. Data may be routed to A, B, or the shifter, and branch conditions (see "Control Section") test the sign bit (R<0) and low bit (R Odd). RM may be written between t3 and t4 with data from Md or Pd.
The RM read address is RBase[0:3],,RSTK[0:3]. For io tasks SubTask[0:1] (discussed in "Slow IO") are or’ed with RBase[2:3]. Each task can thus select from 16 RM registers in the block pointed to by RBase.
Normally, this read address is also used for the write part of the instruction (if any). However, two groups of FF decodes discussed below modify the write address.
The RBase←SC function loads RBase with FF[4:7], selecting any block of 16 registers; RBase←B loads RBase from B[12:15]; Pointers←B loads RBase from B[12:15] while also loading MemBase from B[3:7] (Previous RBase value is used for both the read and write portions of the instruction.). The IFU initializes the emulator task’s RBase to 0 or 1 before dispatching to the first instruction of an opcode.
The STK memory (sometimes called "stack") is accessible only to the emulator (task 0). Since the emulator cannot block, the instruction bit interpreted as BLOCK for io tasks is instead interpreted as StackSelect; when StackSelect is 1, RM is disabled and STK used instead. Like RM, STK stores 256 words x 16 data bits with odd parity on each byte of data. STK is addressed by the 8-bit StkP register, and RSTK controls the adjustment of StkP; StkP may be decremented or incremented by any value between −4 and +3.
Unadjusted StkP is always the read address and normally the write address, but the ModStkPBeforeW FF decode forces adjusted StkP to be used for the write. STK is divided into four separate regions, each 1008 words long. Valid addresses are 1 to 778 within each region. That is, StkP[0:1] select the region, stack overflow occurs at the onset of a instruction that would increment StkP[2:7] > 778, and underflow occurs when location 0 is either read or written or when StkP[2:7] is decremented below 0.
StkP[2:7] are initialized to 0, denoting the empty stack. A push could do StkP←StkP+1 and write in one instruction. A pop does StkP←StkP−1, and the item being popped off can be referenced in the same instruction if desired.
Table 6: RSTK Decodes for Stack Operations
RSTK[0]0 = no underflow on StkP = 0 at start or end
1 = underflow when StkP originally 0 or finally 0.
RSTK[1:3]Meaning
0no StkP change
1StkP←StkP+1
2StkP←StkP+2
3StkP←StkP+3
4StkP←StkP−4
5StkP←StkP−3
6StkP←StkP−2
7StkP←StkP−1
In other words, RSTK[1:3] treated as a signed number are added to StkP[2:7] (StkP[0:1] don’t change.). In the emulator, an attempt to underflow or overflow the stack generates the signal StkError:
StkError = (BLOCK eq 1) & Emulator &
[((StkP[2:7] + RSTK[1:3]) < 0) % ((StkP[2:7] + RSTK[1:3]) > 778) %
((RSTK[0] eq 1) & ((StkP[2:7] eq 0) % ((StkP[2:7] + RSTK[1:3]) eq 0)))]
StkError generates HOLD and wakes up the fault task (task 15) to deal with the situation, so the instruction causing StkError has not been executed when the fault task runs. StkUnd and StkOvf are remembered in flipflops read by the Pd←Pointers function. These get cleared (i.e., recomputed) when the next stack operation is executed by the emulator. The fault task can read them to decide whether stack underflow or overflow action is necessary.
Interpretation of underflow: StkP eq 0 denotes the empty stack. A stack adjustment may occur either by itself or with a read or write stack reference. StkP originally equal 0 underflows if the top of stack is read or written; decrementing StkP below 0 is always an underflow error; StkP equal 0 after modification underflows iff writing at the modified address. Consequently, the assembler sets RSTK[0] equal 1 for a stack reference only when either reading STK and incrementing the pointer or writing at the modified address and decrementing the pointer.
In other words, the microassembler must tell the hardware when to make the StkP equal 0 underflow checks, and it must do this correctly when the ModStkPBeforeW FF decode is used.
StkP can be loaded from B[8:15] using the StkP←B function; however, this is illegal in conjunction with a STK read or write in the same instruction (e.g., T←Stack, StkP←T leaves StkP unchanged).
StkP is saved at t2 of an instruction dispatched to by the IFU. The saved value may be reloaded into StkP at t2 by the RestoreStkP function; RestoreStkP is illegal in conjunction with a STK read or write in the same instruction.
RestoreStkP is useful only if opcodes are restarted after servicing map faults. However, we are also arranging for the IFU state, branch conditions, etc. of an interrupted opcode to be readable and reproducible, so that it will be possible to simply continue from the instruction that faulted. RestoreStkP will be useless if the continue-method of restarting is adopted.
The opcode-restart method effectively prevents use of the IFU entry vector scheme discussed in "IFU Section," degrading performance perhaps 2%, so it is desirable to continue from rather than restart from faults. Also, complicated opcodes may require special-case code in the fault handler before opcode restart is possible, so continuing from the instruction that faulted is likely to be simpler overall.
Two groups of FF decodes change the RM address for the write portion of an instruction.
The first group of 16 FF decodes forces the write address to come from RBase[0:3],,FF[4:7]. This allows different registers in the same group of 16 to be used for the read and write portions of the instruction, or allows STK[StkP] to be used for the read portion and any of the 16 registers pointed to by RBase in the write portion.
The second group of 16 FF decodes forces the top four write address bits to come from FF[4:7]. The complete RM write address becomes FF[4:7],,RSTK[0:3]. This allows an arbitrary RM address to be written without having to load RBase in a previous instruction. Alternatively, if the i’th register in a group of 16 is read from RM, it permits the i’th register in a different group of 16 to be written in the same instruction. In conjunction with a read of STK, RSTK[0:3] will encode the StkP modification, and whatever RM word this happens to point to will be written (Programmers will have to struggle to use this with a STK read.). Note: SubTask does not affect the write address for these functions.
Note that there is no way to read RM and write STK in one instruction.
The RisId FF decode causes Id to be substituted for RM/STK in the A, B, or shifter multiplexing.
There are branch conditions to test R[0] (R<0) and R[15] (R odd). These branch conditions are unaffected by the RisId FF decode; actual data from RM/STK is tested.
Cnt Register
The 16-bit Cnt register is provided for use as a loop counter. Since it is not task-specific, io tasks must save and restore it.
Cnt can be decremented and tested for 0 by the Cnt=0&−1 branch condition; loaded from B[0:15] or from small constants 1 to 16 (FF decodes), and read onto the Pd path (into T or RM/STK) by an FF decode.
Q Register
The 16-bit Q register is provided primarily for use as a shift register with multiply and divide, but will probably be used more widely by the emulator. Since it is not task-specific, io tasks must save and restore it.
Q can be read onto B (BSEL) or onto A (FF); it can be loaded from B (FF) and when FF specifies an external B source in the memory, ifu, or control sections, it can also be loaded from B (BSEL). Q can be left-shifted or right-shifted one (bringing 0 into the vacant bit) by two FF decodes.
T Register
The 16-bit T register is the primary register for data manipulation in the processor. Since it is task-specific io tasks do not have to save and restore it. T can be read onto B (BSEL) or A (ASEL); it can be loaded from Pd or Md (LC).
BSEL: B Multiplexor Select
BSEL normally selects one of the "internal" processor sources for B, as shown in the "Primary" column in the table below (Note that although Md originates in the memory section, it is latched by the processor and appears as an internal B source.). However, the FF field can be used to substitute some other source external to the processor—there are many "external" sources in the control, IFU, and memory sections, and the codes for these are given in Table 11. When an external source is specified, then BSEL instead encodes the destination for B, as shown in the "External" column of the table below.
The sources selected by BSEL are:
Table 7: BSEL Decodes
BSELPrimaryWith External Source
0Md—
1RM/STK—
2T—
3QQ←B *
40,,FFInapplicable because FF is not available to encode an external source
53778,,FFInapplicable
6FF,,0Inapplicable
7FF,,3778Inapplicable
*Note: BSEL decode for Q←B is needed in initializing Dorado from the baseboard or Alto. Because ALUFM contents may be unknown, and data from the Alto is transmitted via the B←Link FF decode, some other field is needed to encode a destination that can then be routed into ALUFM.
The values selected by BSEL=4-7 are 16-bit constants obtained by concatenating the 8-bit FF field with zeroes or ones. When this is done, normal effects of functions are disabled, so external B sources are impossible. In conjunction with a shift operation on A, BSEL = 4 to 7 will cause the shifter controls to come directly from FF rather than from ShC as discussed in "Shifter"; the Q-register sources B when an FF-controlled shift is carried out.
The TisId and RisId FF decodes may be used with the B←T or B←RM/STK BSEL decodes, respectively, to accomplish B←Id.
The "External" decode of BSEL applies with Link, DBuf, Pipe0-Pipe5, FaultInfo, PCX, DecLo, DecHi, and other functions that source B on the backpanel, as selected by the FF decode. For these external sources, BSEL is interpreted as the destination for B rather than the source.
Note: When the memory or control section sources the external B bus, it is illegal to execute arithmetic alu operations; these sources are not electrically stable soon enough to permit the extra 10 ns required for carry propagation. But: if you are sure carries will not propagate into the high 8 bits of ALU result, then the hardware is fast enough.
However: Arithmetic is permitted when the IFU sources the external B bus, provided the previous instruction was not one of the slow B sources from the memory or control sections. This permits (Id)-(PCX’)-1, common in emulator microcode.
This implies that an io task must never block on an instruction that reads B from a slow external source.
Hardware Implementation
The processor’s internal version of B, called Alub, is driven by a 4-input multiplexor when sourced from within the processor; in this case an identical multiplexor drives the external bus, called Bmux (high-true). When the B source is external, both of these multiplexors are disabled, and the backpanel Bmux (low-true) is inverted through a gate onto Alub. The multiplexor arrangement is shown in Figure 3.
The IFU section is on/off of Bmux by t1+6 ns and the processor section is off by t1+7 ns, but the memory and control sections are not on/off until t1+16 ns; hence, a slow Bmux source in the previous instruction prevents Bmux from stabilizing until t1+16 ns of the current instruction, allowing insufficient time to propagate Bmux onto Alub and finish carry propagation. However, because Bmux is gated onto Alub, and the gate shuts off quickly, arithmetic on internal Alub sources is always permissible.
Bmux sources in this manual are given high or low-true names that agree with the way signals appear on Alub. For external sources this is inverted with respect to the sense of these signals on Bmux. However, because external sources cannot feed external destinations (no way to encode this in an instruction), the signal inversion is invisible to programmers.
ASEL: A Source/Destination Control
The AMux drives the A input to the ALU, and is the data source for the read-field (RF←) and write-field (WF←) methods of loading ShC. The shifter also drives A, in which case the AMux is usually disabled.
A copy of the AMux drives the backplane Mar bus on processor memory references. The IFU may also drive Mar, when the processor isn’t using it.
The three-bit ASEL field controls the source and destination for A as follows:
Table 8a: ASEL Decodes When FF is ok*
ASELFF[0:1]Meaning
0 0PreFetch←RM/STK
1Map←RM/STK (emulator or fault task) -or- IOFetch←RM (io task)
2LongFetch←RM/STK
3Store←RM/STK
1 0DummyRef←RM/STK
1Flush←RM/STK (emulator or fault task) -or- IOStore←RM (io task)
2IFetch←RM/STK
3Fetch←RM/STK
2 0Store←Md
1Store←Id
2Store←Q
3Store←T
3 0Fetch←Md
1Fetch←Id
2Fetch←Q
3Fetch←T
4—A←RM/STK
5—A←Id--see "Instruction Fetch Unit"
6—A←T
7—Shift operation—see "Shifter" (uses ALUF)
Table 8b: ASEL Decodes When FF is not ok*
ASELMeaning
0Store←RM/STK
1Fetch←RM/STK
2Store←T
3Fetch←T
4A←RM/STK
5A←Id
6A←T
7Shift operation—see "Shifter" (uses ALUF)
*FF is ok when not used in a long goto, long call, as a BSEL constant, or in an FF-controlled shift.
When FF is ok and ASEL = 0 to 3, the decoding of FF as a function is forced to be in the range 0 to 63. In other words, FF[0:1], stolen to modify the memory operation on A, do not participate in the FF decode. Hence, only functions 0 to 63 can be used in the same instruction with a memory reference.
In the above tables, each instance where the source for A is RM/STK can be overruled by one of the 4 FF decodes for A sources or the FF decodes that put FF[4:7] on A. These FF decodes are illegal with the ASEL or ASEL-FF[0:1] values that select Id or T, and the source for A is undefined when this restriction is violated.
The notation "Fetch←A", "Store←A", etc. in the above table is compatible with the microlanguage. These routing expressions mean, for example, that the displacement originating on A is routed onto the Mar bus on the backplane, added to BR[MemBase] in the memory section and loaded into the memory address register. Then the Fetch, Store, etc. is started as detailed in "Memory Section".
ASEL does a pretty thorough job of encoding possible actions on A: Store← and Fetch← references take the address from RM/STK, T, Md, Id, or Q; other references take the address from RM/STK; LongFetch← takes the low 16 bits of address from RM/STK and high 8 bits from B.
The FF field can be used to select any of the following sources:
FF[4:7](small constant)
RM/STK
Q
T
Md
These functions are illegal except on shifts (ASEL=7) or when the source otherwise selected would be RM/STK (ASEL=0, 1, or 4). On shifts these functions cause the A source to be wire-or’ed with the shifter output (otherwise the A source would be disabled); with references, these functions overrule RM/STK as the source.
Hardware Implementation
A is driven by a 4-input multiplexor as shown in Figure 3. A similar arrangement drives Mar, which is disabled except on memory references or when one of the 8 FF decodes that use Mar is executed; the IFU may use Mar when the processor does not. The 4-input multiplexors are usually disabled on shifts, which OR onto A independently.
However, the A multiplexor is not disabled when the source for A is encoded in FF, so it is possible to OR any A input except Id with the (complemented) shifter data—this is useful for BitBlt and other complicated uses of the shifter. Since shifter data on A is low-true, and since the normal ALU operation is NOT A on shifts, the effect of enabling both the shifter and the normal A multiplexor is [Shiftdata and not A].
ALUF, ALU Operations
The 4-bit ALUF field controls the ALU operation. It addresses a RAM (ALUFM) containing control for the MC10181 ALU chips.
ALUFM is 8-bits wide, of which 6 bits are used. ALUFM[0] controls the carry-in for arithmetic ALU operations. It is a "don’t care" for the 16 logical ALU operations. The XorSavedCarry function causes the saved carry-out of a previous operation to be xor’ed with this bit. The XorCarry function complements the value from ALUFM. ALUFM[3:7] select the ALU function performed as below. The carry-out (task-specific) changes whenever an arithmetic operation is performed in the ALU unless explicitly disabled by the FreezeBC function (freeze branch conditions).
The Carry20 function forces the bit 12 carry-in to one. Assuming that this carry-in would otherwise have been zero, then this function adds 208 to the (arithmetic) ALU output. Adding 208 is expected to be useful because the cache, fast input bus, and fast output bus deal with 208-word munches.
The table below shows the logical and (useful) arithmetic ALU operations.
Table 9: ALUFM Control Values (Octal)
LogicalArithmetic (No Carry)Arithmetic (With Carry)
*1NOT A *0A *0A+1
(NOT A) OR (NOT B) **62*A 2*A+1
(NOT A) OR (B) *14A+B *14A+B+1
All-ones output *22A−B−1 *22A−B
(NOT A) AND (NOT B) *36A−1 A
*13NOT B
A XNOR B (Assembler makes "EQV" and "=" synonyms for XNOR)
A OR (NOT B)
(NOT A) AND B
*23A XOR B (Assembler makes "#" synonym for XOR)
*25B
*27A OR B
All-zeroes output
**33A AND (NOT B)
*35A AND B
A
*System microcode can count on these operations being defined.
**Emulator task can count on these operations being defined.
On a barrel shift (selected by ASEL=7), the first three ALUFM address bits are forced to 1 (ALUF[0:2] selects the kind of shift in this case). The intent of this arrangement is that ALUFM[168] selects the "NOT A" ALU operation. Nearly all shifter operations use this ALU function to route shifter output through the ALU. ALUFM[178] is loaded with assorted controls (i.e., used as a variable) by BitBlt or other opcodes that do more complicated things.
ALUFM can be read onto Pd by the ALUFMEM function or both loaded from B and read onto Pd by the ALUFMEMRW function.
External B sources from the IFU and internal sources are ready in time for arithmetic, but external sources from the memory and control sections are not (see the earlier section on "BSEL: B Multiplexor Select"). Internal A sources except shifter are ready in time for arithmetic. Unless explicitly disabled by the FreezeBC function, the branch conditions ALU<0, ALU=0, Carry’ (ALU carry out’), and Overflow are available for testing on the control card at t3.
The Overflow branch condition, defined as carry-out from bit 0 unequal to carry-out from bit 1, is true iff a signed arithmetic operation yields an incorrect result.
Normally, the ALU is routed directly onto Pd, and Pd is then written into either T or RM/STK. However, several functions route ALU output shifted left or right 1 position onto Pd. Note that the ALU output of this instruction are used (not the previous one) and that ALUcarry is undefined on a logical ALU operation. The right shifts are:
ALU rsh 1(0 onto Pd[0])
ALU rcy 1(ALU[15] onto Pd[0])
ALU arsh 1(ALU[0] onto Pd[0] preserving the sign)
ALU brsh 1(ALUcarry onto Pd[0])
Multiply(ALUcarry onto Pd[0]).
The left shifts are:
ALU lsh 1(0 onto Pd[15])
ALU lcy 1(ALU[0] onto Pd[15])
Divide(Q[0] onto Pd[15])
CDivide(Q[0] onto Pd[15]).
Multiply, Divide, and CDivide have other effects as well discussed later.
Note: The barrel shifter discussed in the "Shifter" section also use the Pd multiplexor for masking, so it is illegal to combine barrel shifts and ALU shifts in the same instruction.
Note: ALU<0, ALU=0, Carry’, and Overflow branch conditions test the ALU output of the previous instruction executed by the task and any shifting or masking that takes place in the Pd input multiplexor does not affect the result of these branch conditions.
Note: The value of Carry’ and Overflow change only on arithmetic ALU operations. However, ALU←A may be either an arithmetic or a logical operation; in order to use XorCarry with ALU←A, we will probably use the arithmetic form of ALU←A, but the consequence of this is that Carry’ will change on ALU←A. Programmers will have to be wary of this.
Note: Overflow is implemented correctly only for the A+B, A+B+1, A-B, and A-B-1 operations; other arithmetic ALU operations (A+1, A-1, 2A, 2A+1, etc.) may modify the branch condition erroneously.
LC: Load Control for RM and T
This field controls the loading and source selection for the RM/STK memory and T register. The eight combinations are:
Table 10: LC Decodes
LC Meaning
0No Action
1T←Pd
2T←Md, RM/STK←Pd
3T←Md
4RM/STK←Md
5T←Pd, RM/STK←Md
6RM/STK←Pd
7T←Pd, RM/STK←Pd
The only missing combination is T←Md, RM/STK←Md. T←Md, RM/STK←Md can be accomplished by combining an LC value of 5 with the TgetsMd FF decode. It is illegal to use TgetsMd with other LC decodes.
FF: Special Function
This field is the catch-all for functions not otherwise encoded in the instruction. For consistency with the hardware implementation, the 8-bit FF field is shown below as a two-bit field FA (= FF[0:1]) and two 3-bit fields, FB (= FF[2:4]) and FC (= FF[5:7]). Field values are given in octal.
The FF field is interpreted as a function iff:
(BSEL not selecting a constant) and
JCN does not select a "long" goto or call
When ASEL selects one of the memory references, the FF decode is forced to be that of FA=0 because the FA field specifies the source for A or alternate memory reference in this case.
The decoding assignments have been made with the following considerations:
Functions that source the external BMux are grouped for easy decode of the signal that turns off the processor’s B-multiplexors.
Operations that might be useful in conjunction with a memory reference are put in the first 64 decodes (FA=0) since FA is decoded as zero on memory references.
Functions decoded by different hardware sections are arranged in groups to reduce decoding logic.
Table 11a: FF Decodes (FA = 0)
FBFCFunction
* The AMux is not disabled when A←xx decodes below are used while ASEL selects a shift.
0-1—A[12:15] ← FF[4:7]
2 0A ← RM/STK
2 1A ← T
2 2A ← Md
2 3A ← Q
2 4XorCarry (complements ALUFM carry bit)—see the "ALUF, ALU Operations" section
2 5XorSavedCarry—see the "ALUF, ALU Operations" section
2 6Carry20 (carry-in to bit 11 of ALU = 1)—see the "ALUF, ALU Operations" section
2 7ModStkPBeforeW (Use modified StkP for write address of STK)
3 0—
3 1ReadMap. Modifies action of Map← (see "Memory Section")
3 2Pd ← Input (checks for IOB parity error)
3 3Pd ← InputNoPE (no check for IOB parity error)
3 4RisId (causes Id to replace RM/STK in A←RM/STK, B←RM/STK, and shifter)
3 5TisId (causes Id to replace T in A←T, B←T, and shifter)
3 6Output ← B
3 7FlipMemBase (MemBase ← MemBase xor 1)
4-5—Replace RMaddr[0:3] by RBase[0:3] and RMaddr[4:7] by FF[4:7] for write of RM;
Forces RM to be written even if STK was read.
60-7Branch conditions (see "Control"). In conjunction with an IFU jump in JCN,
if the condition is true, IFU advance is disabled (see "IFU")
7 0BigBDispatch ← B (256-way dispatch on B[8:15]. See "Control")
7 1BDispatch ← B (8-way dispatch on B[13:15]. See "Control")
7 2Multiply (Pd[0:15] ← ALUcarry,,ALU[0:14]; Q[0:15] ← ALU[15],,Q[0:14];
Q[14] OR’ed into TNIA[10] as slow branch—see "Multiply")
7 3Q ← B
7 4—
7 5TgetsMd (In conjunction with LC=5, this causes T←Md, RM/STK←Md)
7 6FreezeBC (freezes previous values of ALU and IOAtten’ branch conditions for 1 cycle)
7 7Reserved as a no-op
Table 11b: FF Decodes (FA = 1)
FBFCAction
0 0PCF ← B. Load PCF and starts fetching instructions
0 1IFUTest ← B, dismisses junk wakeup, bits used as follows:
0:7 TestFG 8 TestParity 9 TestFault10 TestMemAck
11 TestMakeF←D12 TestFH’13 TestSH’14 enables testing
0 2IFUTick
0 3RescheduleNow (doesn’t set Reschedule branch condition)
0 4AckJunkTW←B. B[15]=1 shuts off junk task wakeups, =0 enables them; B[0:14] ignored
0 5MemBase←B[3:7]
0 6RBase←B[12:15]
0 7Pointers←B (MemBase←B[3:7] and RBase←B[12:15])
10:7Unused
Table 11c: FF Decodes (FA = 1)
FBFCAction
*The following 8 FF decodes drive Mar from A.
20-1Unused
2 2CFlags ← A’ (see Figure 10) (Mar must be stable during prev. instr.)
2 3BrLo ← A. BR[16:31] ← A[0:15]
2 4BrHi ← A. BR[4:15] ← A[4:15]
2 5LoadTestSyndrome from DBuf (see Figure 10)
2 6LoadMcr[A,B] (see Figure 10)
2 7ProcSRN ← B[12:15]
3 0InsSetorEvent ← B. If B[0] = 0, then B[4:15] are controls for EventCntA and EventCntB;
if B[0] = 1, then B[6:7] are loaded into the IFU’s InsSet register.
3 1EventCntB ← B or equivalently GenOut←B (General output to printer, etc.)
3 2Reschedule
3 3NoReschedule
B data must setup during previous instruction and not glitch when writing IFUMLH/RH—see IFU section.
3 4IFUMRH ← B. Packeda←B.5, IFaddr’←B[6:15]
3 5IFUMLH ← B. Sign←B.0, PE[0:2]←B[1:3], Length’←B[4:5], RBaseB’←B.6,
MemB←B[7:9], TPause’←B.10, TJump←B.11, N←B[12:15]
3 6IFUReset. Reset IFU
3 7BrkIns ← B. Opcode←B[0:7] and set BrkPending
4 0UseDMD (see "Control Section")
4 1MidasStrobe ← B (see "Control Section")
4 2TaskingOff
4 3TaskingOn
4 4StkP ← B[8:15]
4 5RestoreStkP
4 6Cnt ← B (overrules Cnt=0&−1 in the same instruction)
4 7Link ← B (overrules loading of Link by Call or Return in same instruction)
5 0Q lsh 1 (Q[0:14] ← Q[1:15], Q[15] ← 0)
5 1Q rsh 1 (Q[1:15] ← Q[0:14], Q[0] ← 0)
5 2TIOA[0:7] ← B[0:7] (Note: loaded from left-half of B)
5 3—
5 4Hold&TaskSim ← B (Hold reg ← B[0:7], Task reg ← B[9:15].
See "HOLD and Task Simulator")
5 5WF ← A (load ShC with write-field controls—see "Shifter")
5 6RF ← A (load ShC with read-field controls—see "Shifter")
5 7ShC ← B (see "Shifter")
6 0B ← FaultInfo’. B[8:11]←SRN for 1st fault, B[12:15]←number of faults
6 1B ← Pipe0 (B←VaHi—see Figure 10)
6 2B ← Pipe1 (B←VaLo—see Figure 10)
6 3B ← Pipe2’ (see Figure 10)
6 4B ← Pipe3’ (B←Map’—see Figure 10)
6 5B ← Pipe4’ (B←Errors’—see Figure 10)
6 6B ← Config’ (see Figure 10)
6 7B ← Pipe5’ (see Figure 10)
7 0B ← PCX’
7 1B ← EventCntA’ (see "Other IO and Event Counters")
7 2B ← IFUMRH’ (low part of IFUM)
7 3B ← IFUMLH’ (high part of IFUM)
7 4B ← EventCntB’ (see "Other IO and Event Counters")
7 5B ← DBuf (normally non-task-specific data from last Store← — see "Memory")
7 6B ← RWCPReg (= Link←B’ and B←CPReg)
7 7B ← Link
Table 11d: FF Decodes (FA = 2)
FBFCAction
0-1—RBase ← FF[4:7]
2-3—Replace RMaddr[0:3] by FF[4:7] for write of RM.
Forces RM to be written even if STK was read.
4—TIOA[5:7] ← FF[5:7] (TIOA[0:4] unchanged)
50-3MemBaseX ← FF[6:7]
(MemBase[0] ← 0, MemBase[1:2] ← MemBX[0:1], MemBase[3:4] ← FF[6:7])
54-7MemBX ← FF[6:7]
60-1—
6 2Pd ← ALUFMRW (Pd ← ALUFMEM as below, ALUFMEM ← B.8, B[11:15])
6 3Pd ← ALUFMEM (Pd.0 ← DMux data, Pd.8 and Pd[11:15] ← ALUFMEM[ALUF])
6 4Pd ← Cnt (If Cnt=0&−1 in same instruction, unmodified value is read)
6 5Pd ← Pointers (Pd[1:2] ← MemBX, Pd[3:7] ← MemBase,
Pd[8] ← StkOvf, Pd[9] ← StkUnd, Pd[12:15] ← RBase)
6 6Pd ← TIOA&StkP (Pd[0:7]←TIOA, Pd[8:15]←StkP; if the instruction modifies StkP
concurrently, the MODIFIED value is read)
6 7Pd ← ShC
7 0Pd ← ALU rsh 1 (Pd[0] ← 0)
7 1Pd ← ALU rcy 1 (Pd[0] ← ALU[15])
7 2Pd ← ALU brsh 1 (Pd[0] ← ALUcarry)
7 3Pd ← ALU arsh 1 (Pd[0] ← ALU[0] preserving sign)
7 4Pd ← ALU lsh 1
7 5Pd ← ALU lcy 1
7 6Divide (Pd[0:15]←ALU[1:15],,Q[0]; Q[0:15]←Q[1:15],,ALUcarry)
7 7CDivide (Pd[0:15]←ALU[1:15],,Q[0]; Q[0:15]←Q[1:15],,ALUcarry’)
Table 11e: FF Decodes (FA = 3)
0-3—MemBase ← FF[3:7]
4-5—Cnt ← small constant (Cnt[0:10] ← 0, Cnt[11] ← 0 if FF[4:7] # 0 else 1,
Cnt[12:15] ← FF[4:7]; i.e., values of 1 to 16 are loadable)
6-7—Wakeup[n] — Initiate wakeup request for task FF[4:7]
Multiply and Divide
The Multiply, Divide, and CDivide functions operate on unsigned 16-bit operands. Unsigned rather than signed operands are used so that the algorithms will work properly on the extra words of multiple-precision numbers.
The actions caused by these functions are as follows:
Multiply:
Result ← ALUCarry..ALU/2
Q ← ALU[15]..Q/2
Next branch address ← whatever it is OR 2 if Q[14] is 1.
Divide, CDivide:
Result ← 2*ALU..Q[00]
Q ← 2*Q..ALUCarry -or- 2*Q..ALUCarry’
Complete examples for Multiply and Divide subroutines are given in the microassembler document. The inner loop time is 1 cycle/bit for multiply and 2 cycles/bit for divide.
Shifter
See Figure 4.
Dorado contains a 32-bit barrel shifter and associated logic optimized for field extraction, field insertion and the BitBlt instruction.
The shifter is controlled by a 16-bit register ShC. To perform a shift operation, ShC is loaded in one of three ways discussed below with 14 bits of control information, and one of eight shift-and-mask operations is then executed in a subsequent instruction. Alternatively, (a limited selection of) shift controls may be specified in FF and BSEL concurrent with a shift; in this case, ShC is not modified. ASEL=7 causes a shift and ALUF[0:2] select the kind of masking.
The execution of a shift instruction (after ShC has been loaded in a previous instruction) proceeds as follows:
ShC[2] selects between T and RM/STK for the left-most 16 bits input to the shifter; ShC[3] selects between T and RM/STK for the right-most 16 bits. Using the RisId or TisId FF decode in the same instruction allows Id to replace either T or RM/STK in the shift. This 32-bit quantity is then left-cycled by the number of positions (0-15) given by ShC[4:7]. When ShC[2] and ShC[3] are both 1, then the shifter left-cycles T; when both 0, RM/STK. In these cases it operates as a 16-bit cycler. When ShC[2] and ShC[3] are loaded with complementary values, then it left-cycles the 32-bit quantity R..T or T..R.
The low order 16 bits of shifted data are placed complemented on A by the shift, and normal A source is disabled (except when the source for A is encoded in FF—see the ASEL section).
ALUF[0:2] select one of eight mask operations (see below) and the first three ALUFM address bits are forced to 1, so that the ALU operation in either ALUFM 168 or ALUFM 178 can be performed. This must be a logical ALU operation using the shifted data on A and data on B because there is insufficient time to propagate carries for an arithmetic operation. The intent is that ALUFM 168 contain the control for the "NOT A" ALU operation normally desired, while ALUFM 178 is used by BitBlt and other opcodes that need computed ALU operations.
ALU output passes to the masking logic. The mask operation determines which of two independent masks in ShC are applied to the data. LMask contains 0 to 15 ones starting at bit 0, RMask 0 to 15 ones starting at bit 15. The masked area(s) of ALU output corresponding to 1’s in the mask are replaced either with zeroes or with corresponding bits from Md according to the shift-and-mask function selected. Replace-with-Md generates HOLD if Md isn’t ready yet, and the timing for this is the same as Md onto B (i.e., data is never ready sooner than the second instruction after the Fetch←).
Masked data is routed onto Pd, then sent to the destination specified by LC.
Note: The Pd input multiplexor is used to carry out masking, so it is illegal to combine a shifter operation with an ALU shift in the same instruction.
Three functions load ShC: RF←A and WF←A treat A[8:15] as a Mesa field descriptor and transform the bits appropriately before loading ShC; they also load ShC[2:3] from A[2:3]. ShC←B allows an arbitrary value to be placed in ShC (used by BitBlt).
Microcode for the Mesa RF (Read Field) and WF (Write Field) opcode is shown as an example of the use of the shifter. In these examples, a and b are the two operand bytes for the opcode, as discussed in "Instruction Fetch Unit." RF and WF both take a pointer from the top of the stack and add a to it as a displacement. RF fetches the word, and pushes the field specified by b onto the stack; WF fetches the word, and inserts a field from the rightmost bits of the word in the second position of the stack into it, then restores the word to memory.
RF:IFetch←Stack, TisId;*Calculate the pointer. a replaces BR[MemBase] (MDS);
*this value is then added to Stack to compute the
*address for the pointer.
Stack←Md, RF←Id;*IFU supplies b, the field descriptor
IFUJump[0], Stack←ShiftLMask;*Right-justify & mask the field, IFU to next instruction
WF:T←(IFetch←Stack&-1)+T, TisId;*Start fetch of word containing field
WF←Id, RTemp ←T;*IFU supplies b, the field descriptor
T←ShMdBothMasks[Stack&-1];
IFUJump[0], Store←RTemp, DBuf←T;
The shift controls come directly from FF if ASEL=7 (a shift) and if BSEL = 4, 5, 6, or 7, selecting a constant. This specifies complete shift control in the instruction which does the shift, so ShC doesn’t have to be loaded in a previous instruction, and ShC isn’t clobbered, so io tasks don’t have to save and restore it. When BSEL controls a shift in this way, the B source is forced to be Q.
The mask operations are as follows:
Table 12: ALUF Shift Decodes
ALUF[0:2]*
0ShiftNoMask
1ShiftLMask—masked bits on the left-hand-side of the word replaced with 0’s
2ShiftRMask—masked bits on the right with 0’s
3ShiftBothMasks—masked bits on both sides replaced with 0’s
4ShMdNoMask—unused (falls out of decoding)
5ShMdLMask—masked bits replaced with Md
6ShMdRMask—masked bits replaced with Md
7ShMdBothMasks—masked bits replaced with Md
*ALUF[3] selects the ALU operation in either ALUFM 168 or 178
ShiftLMask implements right shift and load-field operations; ShiftRMask implements left shift; ShiftBothMasks deposits the selected field into a word of zeroes; ShMdBothMasks deposits the selected field into data coming from memory; and ShiftNoMask implements various cycle operations.
Note: On a shift the ALU branch conditions apply to the unmasked ALU output.
Hold and Task Simulator
The hold and task simulators are provided for hardware checkout (programmers skip this section).
Hold&TaskSim←B loads HOLDSIM[0:7] from B[8:14]..0 and TASKSIM[0:6] from B[1:7]. HOLDSIM is a recirculating shift register in which the presence of a 1 in bit 7 causes HOLD two instructions later. For example, Hold&TaskSim←2008 will complete three instructions after the Hold&TaskSim←, HOLD the next cycle, and HOLD every seventh instruction (i.e., every eighth cycle) thereafter. Since this register cannot be loaded with all 1’s and since its clocks are not disabled by HOLD, HOLD of infinite duration is impossible.
To disable this debugging feature, the register must be loaded with 0.
TASKSIM is a seven-bit counter which determines the number of cycles before a task wakeup occurs. The task selected for wakeup must be jumpered on the backplane (else no-op). Whenever TASKSIM is loaded with a non-zero value, it counts up to 1778, then generates a wakeup request when the counter overflows to 2008. The wakeup request remains true until TASKSIM is reloaded.