This commit mashes a few changes together, so I'm going to explain them one at a time.  However, since I cannot annotate individual edits easily, I'll use notes identified by (hg.note.X) in the source.
This commit mashes a few changes together, so I'm going to explain them one at a time.  However, since I cannot annotate individual edits easily, I'll use notes identified by (hg.note.X) in the source.

hg.note.1
    When debugging why a long-running program isn't working right, it's often necessary to pour through a huge set of timing diagrams.  Finding your place after editing a Verilog module is tedious.  So, I alter the code to make use of the otherwise unused bit 4 of an ALU operation, so that its value is pushed out to a "test point", or tp_o.  That way, I can use iSim's ability to find a value on a signal to quickly "jump" to the part of the timing diagram I'm interested in.  I know that part is relevant to the code being debugged because I alter the code so as to trigger the test point.

hg.note.2
    When writing a value to memory, the common J1 idiom involves using two consecutive DROP instructions.  The first DROP has a bit set which causes the CPU to assert its DAT_WE_O signal while the write is in progress, while the second doesn't.  The basic idea is to store the value of S into the memory location T.  But, since we are executing a DROP, and we compute the subsequent processor state combinatorially, it ends up being the case that we write S into the address S' (assuming T, S, and S' are the 1st, 2nd, and 3rd top of the data stack).  So, we need to cache the previous contents of the T and S values to work around DROP's intended function for the express purpose of writing.

    write_addr and write_data are internal registers which always reflect the last known values of T and S.

hg.note.3
    Related to note 2 above, we need to add a multiplexer to the output of DAT_ADR_I and DAT_DAT_O so that we assert write_addr and
    write_data while actually executing a write instruction.  Otherwise, we get the current stack state, which may be different than we
    intend.

hg.note.4 and
hg.note.5
    See comments included.  It's pretty self-explanatory.  I only added the reference to (hg.note.5) to make it easier to jump around the source to collect related code segments.

hg.note.6
    Fixed a bug which caused unconditional jumps to pop the data stack.  Behaviorally, it matched the logic found in the jump-if-zero instruction.  Obviously, unconditional jumps should never pop anything.

8l/kestrel,8l/kestrel,sam-falvo/kestrel,sam-falvo/kestrel,sam-falvo/kestrel,KestrelComputer/kestrel,KestrelComputer/kestrel,KestrelComputer/kestrel,8l/kestrel,8l/kestrel,sam-falvo/kestrel,8l/kestrel,KestrelComputer/kestrel,8l/kestrel