All of these diagnostics have been debugged against Lizard's machine simulation by first loading the diagnostic with "quad -cx GenDebugger GenXXX" (where "GenXXX" is the name of the diagnostic); several diagnostics then require that you use the interpreter to turn off Lizard's more careful error checking by doing "← LizardLiverImpl.careful ← FALSE"; finally do "Run". The diagnostics assume that Pause[] and Halt[x] will stop simulation and report their location, and Lizard has facilities for showing the values in registers. The diagnostics also assume that transferring control to undefined locations will either cause an IFU page fault, if the page has no declared memory locations on it, or execute a Pause[] opcode, if the page exists but the particular location hasn't been initialized (Or the simulator can give an "outside defined envelope" message when this occurs.). Similarly, they assume that reading or writing an undeclared memory location causes an EU page fault.

The assumed initial condition established by Reset is as follows:

All of the diagnostics execute Halt[177777B] as their last instruction; this normally means that the diagnostic completed all tests without error. In the event of an error, a one-byte Pause opcode (0) will usually be executed, or an "outside defined envelope" message may be given.

A comment at the beginning of each file gives the number of instructions executed by the diagnostic and the PC and cycle at which it terminates when correctly executed.

Each diagnostic consists of a procedure called "All" inside which one procedure is defined for each separate test; following these definitions are procedure calls which instantiate the diagnostic. Execution of every diagnostic begins at the Reset trap location in GenDebugger; the Reset code finishes with a jump to userBasePC = 4040000B and sets the output PC to this location. The first instruction instantiated by the diagnostic is then placed at userBasePC. For example, in GenReg the definitions inside "All" are followed by the following statements which instantiate the diagnostic:

The Reset code in GenDebugger will be followed by the code instantiated by GenEUSL[], which in turn is followed by the code instantiated by GenIFUSL[] and a Halt. (These statements would be followed by statements to instantiate Traps and Xops, though there aren't any in GenReg.) If it is necessary to "home in" on an error being reported by the diagnostic, one approach is to comment out the instantiating procedures selectively until only the one detecting a problem remains. Then examine that procedure to decide how to proceed. Often, a test sequence is defined by a procedure which is called a number of times with different test values; these can be selectively commented out to isolate a particular set of test values that fails.

DebuggerDefs.mesa and GenDebugger.mesa must be understood to run the diagnostics.

DebuggerDefs.mesa defines two BOOLEAN switches, withSoftCard and massiveTesting. The first step in using the diagnostics is to edit these switches into the desired configuration, recompile everything, and build new quad files. DebuggerDefs.mesa also defines the table locations where machine state is saved by GenDebugger.

Normally withSoftCard = massiveTesting = FALSE for testing with slow simulators, TRUE for testing with the Softcard. However, all diagnostics assembled assembled with withSoftCard = TRUE, except GenTraps, will also run under Lizard, though testing will not be as thorough. massiveTesting = TRUE enables additional tests; presently this doesn't do much, but someday it might. withSoftCard controls conditional assembly of diagnostic code which must be different with the Softcard than with Lizard. When withSoftCard = TRUE, all memory references in the diagnostic are confined to word addresses [1,000,000B..2,000,000B) or, equivalently, to byte addresses [4,000,000B..10,000,000B); in addition, tests involving the CST instruction, which is not supported by the Softcard, are disabled. When withSoftCard = FALSE, these restrictions are relaxed for more thorough testing of the PC and memory address logic.

GenDebugger must be loaded ahead of each diagnostic described below. Its purpose is to provide the Reset code and a debugging interface when diagnostics are run on the Softcard; it implements the Reset, Pause[] (opcode 0), and Halt[x] (opcode 377B) traps. Only the Reset trap is used when diagnostics are run under Lizard.

On the Softcard, Pause[] or Halt[] execute the Xop procedures defined in GenDebugger; these save the state of the IFU and EU in storage for access by a Daybreak program using the Softcard, wait for the Softcard to signal "proceed", and then reload the machine state and continue. For the diagnostics below, no purpose would be served by continuing, so the debugger serves principally to save the state of the machine where it can be examined. The details of GenDebugger operation are described by comments in the source file.

When run under Lizard, Pause[] or Halt[x] stops simulation, but bugging "Run" again causes execution to continue at the Xop trap for the opcode; this feature can be used to debug the GenDebugger module itself using Lizard. The abbreviateReset BOOLEAN switch must be used when GenDebugger is itself debugged.

The first test executes all the different unconditional jumps. All code runs in Kernel mode with traps disabled. For testing with the Softcard, the withSoftCard BOOLEAN switch must be set TRUE; this switch disables the JQB tests which go to storage locations outside the 1 megabyte area supported by the Softcard. For testing with Lizard, withSoftCard can be either TRUE or FALSE, but more thorough testing occurs if the switch is FALSE.

First, the relative jumps JDB and JB are exercised to determine that the displacement bits of these opcodes and the PC adder generate and propagate logic works. Next, J1, J2, J3, and J5 are tested. Finally, using JQB, each PC bit is tested in isolation by jumping to a sequence of locations.

Because of my unfamiliarity with the PC adder, this test will not thoroughly exercise the carry propagate terms of the adder, though many cases are tested. No page faults should occur.

Machine features tested by this diagnostics are as follows:

1) Opcodes.

2) All bits of the PC (when withSoftCard = FALSE).

3) All bits of the PC adder with carry being generated and not generated from each bit position, and with some carry propagation situations.

This diagnostic is run from Lizard by:

GenLICJ is the most basic diagnostic for non-jump instructions; it presupposes that GenJumpTest completes successfully; no traps are enabled during the diagnostic, which runs in Kernel mode, and no faults, traps, or procedure calls should occur. Equality comparisons on the conditional jumps require most of the EU's adder to work. Initially, reasonably thorough testing is carried out using LIQB, RJEB, RJEBJ, RJNEB, and RJNEBJ opcodes with stack addressing modes. Each of the 32 bits of LIQB is tested individually. RJEB and RJNEB equality comparisons are tested with each argument in the matching and complementary state and 0. For example, in testing the value 4, comparisons would be done as follows:

The tests are done using both the EU's A bypass path and no bypass path. Then the B bypass path is tested by using RAND to move [s] into const0 before comparing const0 to [s]. The LIQB test should reveal problems in the K bus, EU equality comparison, EU bypass and direct paths, and IFU conditional jump mechanism. It will not be obvious from a failure which of LIQB, RJEB, RJNEB, K bus, A direct path, B direct path, A bypass path, or B bypass path has failed; but failure of one of these should result in the program hitting a Pause.

Next, LIDB is tested against LIQB and then LIB is tested against LIDB using RJEB and RJNEB.

Finally, JEBB, JEBBJ, JNEBB, and JNEBBJ are tested against LIB.

Machine features tested by this diagnostic are as follows:

1) Push of immediate constant.

2) Register comparing conditional jumps (Rb = [S - 1]- only and Ra = const0 or [S]-).

3) Literal match conditional jumps.

4) All 32 K bus bits.

5) All 32 bits of EU subtraction.

6) EU A and B direct paths and bypass paths.

This program is run from Lizard by:

This diagnostic requires GenLICJ and GenJumpTest to work. No faults or traps should occur during this test, which runs in Kernel mode.

The first test is generated by GenEUSL which tests EU regsiters with no traps enabled. LIQB and SIP are used to write registers; then LIP, LIQB, RJEBJ are used to read back and compare each value read against what was written. All the EU registers except 1, 2, and const0 are tested first; then registers 1 and 2 are tested; const0 is not tested because of its implicit use in one-operand opcodes such as LIQB and because it is hard-wired to the value 0. Two passes of testing are carried out; first pass values written into consecutive registers are 1, 2, 4, 8, ..., etc. (cycling a single-bit value each time); second pass values complement those written in the first pass.

The second test is generated by GenIFUSL, which tests the IFU stack and ifuSLimit registers with no traps enabled; ifuXBus and ifuStatus registers are not tested. The method of testing and values used in testing are similar to the EU test described above. The first method uses SIP[ifuEldestL / PC] to push L and PC and LIP[ifuEldestL / PC] to read and check results; all 15 levels of the ifu stack are written and then all are read and checked.

The second method uses LFC to advance the ifu stack position and SIP[ifuYoungestL / PC] to write values; it checks the results with LIP[ifuEldestL / PC]; all 15 levels are tested. The third method pushes and writes the PC with LFC and writes L with SIP[ifuYoungestL]; it reads and checks by doing a RETN and using LIP[ifuYoungestL] to check L. At the conclusion of this test, the ifu stack, ifuYoungestL/PC, ifuEldestL/PC, and the parts of LFC and RETN associated with the PC have been tested. The parts of LFC and RETN associated with L and S are have not been tested, however.

Machine features tested by this diagnostic are as follows:

1) Read and write special registers.

2) Partial testing of procedure call and return with respect to correctly using 15 levels of the IFU stack, pushing and popping the PC and L.

This diagnostic can be run from Lizard by:

This diagnostic, which runs in Kernel mode with traps disabled, assumes that operations tested by GenJumpTest, GenLICJ, and GenReg all work. It tests all the S and L adjusting opcodes and XOP's. It requires "← LizardLiverImpl.careful ← FALSE" to the interpreter before execution. Machine features tested are as follows:

1) S and L adjusting opcodes.

2) Undefined operations.

The Pause Xop (0) and the Halt Xop (377b) are not tested. Also, the following Xops have undefined behavior and are not tested either in this diagnostic or others: 311B, 313B, 337B, 340B, 344B, 350B, and 354B.

This diagnostic can be run from Lizard by:

This diagnostic assumes that operations tested by GenJumpTest, GenLICJ, GenReg, and GenXopLS all work; any failure results in a Pause[] and successful completion is indicated by a Halt[177777B]. The operation of the IFU procedure stack for non-trapping cases was tested by GenReg. All code runs in Kernel mode with traps disabled.

This diagnostic performs the following tests:

1) Procedure calls when they aren't supposed to trap.

2) Procedure return instructions.

This diagnostic can be run from Lizard by:

This diagnostic assumes operations tested by GenJumpTest, GenLICJ, and GenCall work.

The JSR (PC-relative stack jump) and JSD (absolute stack jump) opcodes are tested in Kernel mode with traps disabled in such a way that every bit in the back path from the EU to the IFU is individually tested.

The SFC opcode is tested by executing a sequence of calls that exercises all the PC bits without overflowing the IFU call stack. Before each call, 200B is added to a counter at [S] which is initially 0. Then RETN is executed to return from each of the calls; before each RETN, 1 is added to the counter at [S]. After all the calls and returns have been executed, the counter is checked to make sure that control has successfully passed through all the SFC and RETN opcodes.

Halt[177777B] is executed at the successful end of the test. It is assumed that the simulator stops execution on either Pause or Halt.

Machine features tested by this diagnostic are as follows:

1) JSR PC ← PC+[S]; S ← S-1.

2) JSD PC ← [S]; S ← S - 1.

3) SFC Call proc at [S]; S ← S-1.

This diagnostic can be run from Lizard by:

This diagnostic assumes that operations tested by GenLICJ and GenRegCall all work. No faults, traps, or procedure calls should occur upon any error); no EU memory references are made; no EU arithmetic is used except that which results from equality comparisons on conditional jumps; and all code is executed in Kernel mode with traps disabled.

All register-to-register move operations are tested by using RJEB/RJEBJ to compare the value in the destination register with the value in the source register after executing the move. The program presently tests each operation with the values 0 and -1. Opcodes tested by this diagnostic are as follows:

1) Register-to-register moves

This program is run from Lizard by:

This diagnostic assumes that operations tested by GenLICJ, GenCall, and GenReg all work. No faults, traps, or procedure calls should occur; no EU memory references are made; no EU arithmetic is used except that which results from equality comparisons on conditional jumps; and all code is executed in Kernel mode with traps disabled.

First, the logic operations RAND, ROR, and RXOR are tested using every bit combination with stack arguments; these tests aim primarily at verifying the hardware's ability to execute the AND, OR, and XOR operations. Then, the RRR format addressing modes are thoroughly checked using ROR. Next, the QR format addressing modes are tested using QAND to test the argument specified in 2 bits and QOR to test the argument specified by 6 bits.

Opcodes tested by this diagnostic are as follows:

This program is run from Lizard by:

This diagnostic requires GenLICJ, GenReg, GenCall, and GenLogic to work correctly. The addressing modes for RRR and QR format opcodes are assumed to have already been tested by GenLogic, so the tests in GenArith are not particularly concerned with the registers from which the values being tested derive. The purpose of the diagnostic is to test all arithmetic opcodes except the Lisp arithmetic opcodes, and it is run entirely in Kernel mode with traps disabled.

First, addition is tested using RUADD; carry generation is tested for each of the 32 bit positions by seeing whether the presence of a 1 in the same bit position of both arguments correctly causes a carry into the next higher bit and the absence of a 1 in either argument correctly causes no carry; the carry-out of the adder is also tested. Then carry propagation is tested by adding -1 to each of 1, 2, 4, ....

Next, the inverter used by subtraction and adder carry-out is tested using RUSUB.

Finally, the various add and subtract opcodes are tested on various values, some of which cause integer overflow.

Opcodes tested by this diagnostic are as follows:

This diagnostic can be run from Lizard by:

The purpose of the diagnostic is to test all Lisp arithmetic opcodes. In Lisp arithmetic, the Carry bit is not used as an input, and is set to 0 always; if either operand or the result is not in the range [-229..229) (top three bits being all 0s or all 1s), a Lisp NaN (Not a Number) trap is taken.

This diagnostic requires GenLICJ, GenReg, GenCall, GenLogic, and GenArith to work correctly. The addressing modes for RRR and QR format opcodes are assumed to have already been tested by GenLogic, and basic adder operation is assumed tested by GenArith, so GenLisp is principally concerned only with testing distinctive properties of Lisp arithmetic. Execution is entirely in Kernel mode with traps disabled.

Opcodes tested by this diagnostic are as follows:

This diagnostic can be run from Lizard by:

The purpose of GenRBC is to test the arithmetic comparison conditional jumps and bounds-checking opcodes; this is done entirely in Kernel mode with traps disabled. Since, addressing modes for RRR and QR format opcodes have been tested by GenLogic and adder operation by GenArith, the tests in GenRBC are concerned primarily with testing only the unique properties of the opcodes being tested.

This diagnostic requires GenLICJ, GenReg, GenCall, GenLogic, and GenArith to work correctly.

Opcodes tested by this diagnostic are as follows:

1) Arithmetic comparison conditional jumps

2) Conditional trap opcodes

This diagnostic can be run from Lizard by:

This diagnostic requires GenLICJ, GenReg, and GenLogic to work correctly. No faults, traps, or procedure calls should occur, and all code is executed in Kernel mode with traps disabled. No EU memory references are made; no EU arithmetic is used except that which results from equality comparisons on conditional jumps.

SHL, SHR, SHDL, SHDR, and RFU are each tested in a sequence of 21 instructions which is replicated for a variety of input values, shift counts, and masks.

The following opcodes are tested:

This diagnostic can be run from Lizard by:

This diagnostic requires GenLICJ, GenReg, GenLogic, GenCall, and GenArith work correctly. No procedure calls, page faults, or traps should occur during testing; and all code is executed in Kernel mode.

During the first test, SRI0 is used to write data values into storage; then the values are read back with LRI0 and checked; the values written are 1, 2, 4, ..., etc. so this tests the PBus bits. During the second test, the addressing is tested by choosing addresses with similar patterns and again writing with SRI0 and reading with LRI0.

After addressing and data values are exercised with SRI0 and LRI0, the other operations are tested by writing consecutive storage values using all the other write opcodes and then reading the values back with the read opcodes.

Finally, the CST opcode is tested.

The following opcodes are tested:

1) Load register from memory instructions

2) Store register into memory instructions

3) Conditional store instruction

This diagnostic can be run from Lizard by:

This diagnostic requires GenLICJ, GenReg, GenLogic, GenCall, GenArith, and GenRW to work correctly. No page faults or traps should occur; all code is executed in Kernel mode with traps disabled.

The following opcodes are tested:

This diagnostic can be run from Lizard by:

Unlike the other diagnostics, withSoftcard = FALSE is required to run this diagnostic under Lizard.

For thorough testing, this diagnostic should be run last since it executes many different instructions in its test of user mode (GenJumpTest, GenLICJ, GenReg, and GenXopLS are the most important prerequisites.). However, when testing with simulators, this diagnostic provides a good quick test of the IFU and EU. Unlike most other diagnostics, XPause[] (opcode 2, a 1 byte Xop) is used to report most failures instead of Pause[] (opcode 0); XPause[] turns off user mode and disables traps, if necessary, then jumps to the debugger.

It performs the following tests:

1) That Kernel function call and return works.

2) That SIP[ifuYoungestL] and LIP[ifuYoungestL] correctly set and read the user mode and trap enable status bits for the caller's context and that a RET to the context with the changed status behaves correctly for that status. (Reading and writing ifuYoungestL and ifuEldestL was tested in GenReg; only correct enabling and disabling of traps and correct entering of user mode is tested here).

3) That all instructions legal in user mode don't trap, and those illegal in user mode cause a mode fault trap. Only one Xop of each length (1, 2, 3, and 5 bytes) is tested, only one of the 16 opcodes in each of the LRIn, SRIn, LRn, SRn, and LCn groups is tested. The illegal instructions are all SIP's, and LIP[IFUEldestPC] (an active operation).

4) That any write of a constant or aux0 to aux7 causes a mode fault.

5) When IFUStatus[TrapsEnabled] = TRUE:

6) That an IFU page fault occurs in sequence when jumping, calling, returning, falling through, or conditionally jumping (predicted both ways) into an undeclared page.

7) That an IFU page fault does not occur when the untaken path of a conditional jump (predicted both ways) lies in an undeclared page.

8) That an EU page fault occurs in the proper sequence on memory read, memory write, CST, and SFCI instructions; registers which would have been affected by the faulting instruction are not modified; and the euMAR register is loaded with the memory address of the fault.

9) That mode fault trap prevails over bounds check, overflow, NaN, EU stack overflow, and EU page fault.

10) That an EU stack overflow trap is lower priority than all other traps.

(Since memory faults, bounds check, and overflow or NaN are three mutually exclusive groups of traps, the relative priority of these does not have to be tested. Also, reenabling traps with an EU or IFU stack overflow condition existing is illegal.)

This diagnostic can be run from Lizard by:

NOT DEBUGGED YET.

This diagnostic tests a few loose ends that could not conveniently be tested in GenTraps.

1) Verify that with traps enabled IFU stack overflow trap prevails over an IFU page fault trap that causes the IFU stack overflow condition.

2) ****Verify that EU stack overflow trap prevails over reschedule when a SIP enables traps and the EU stack overflow and reschedule-waiting conditions are both true.

This diagnostic can be run from Lizard by:

The following opcodes or features are not presently tested for various reasons.

1) The three IO opcodes are not tested. In the definitions below, Address = AlphaZ and PCommand = BetaZ; the high-order bit of PCommand is 0 on a non-cache operation, 1 on a cache operation; the low-order bit of PCommand is 0 on a read or 1 on a write. On cache operations bits [1..4] determine which bytes of a cache memory word are affected (10b writes the high-order byte only, 4b the second byte only, 2b the third byte only, and 1b the least significant byte only; 14b the high two bytes; etc.) and bits [5..6] determine which cache operation is performed.

2) The machine state after reset is not verified (no specification available).

3) The two high-order memory address bits are only tested in the zero state because of a Lizard limitation. When withSoftCard = TRUE, only the region [1,000,000B..2,000,000B) is tested.

4) The undefined opcodes are never tested.

5) EUWriteFault, MemAccessFault, IOAccessFault, and Reschedule are not tested (not supported by Lizard).

6) That IFU stack overflow occurs in preference to a mode fault when traps are enabled on a user mode RADD that gets a mode fault trap with the IFU stack going into overflow at the onset of the trap (Lizard bug); tests for this are commented out in GenTraps.

7) IFU page fault priority over EU stack overflow.