Fixed the evaluation of register operands for the XOR opcode (this slipped through the cracks, since it doesn't use readSrcWord())

This commit is contained in:
Jeff Parsons 2016-11-20 13:45:08 -08:00 committed by Jeff Parsons
commit 48047c4a60
5 changed files with 61 additions and 12 deletions

View file

@ -1243,15 +1243,15 @@ PDP11.JSR_CYCLES = [
PDP11.opJSR = function(opCode)
{
/*
* Since JMP and JSR opcodes have their own unique timings for the various dst modes, we must snapshot
* nStepCycles before decoding the mode, and then use that to update nStepCycles.
* Since JMP and JSR opcodes have their own unique timings for the various dst modes, we must
* snapshot nStepCycles before decoding the mode, and then use that to update nStepCycles.
*/
this.nSnapCycles = this.nStepCycles;
/*
* TODO: Determine whether or not the SRCMODE operand (regsGen[reg]) should be snapped BEFORE or AFTER we
* decode the DSTMODE operand. Doing it AFTER seems a bit risky.
*/
var addr = this.readDstAddr(opCode);
/*
* As per the WARNING in readSrcWord(), reading the SRC register AFTER decoding the DST operand
* is entirely appropriate.
*/
var reg = (opCode >> PDP11.SRCMODE.SHIFT) & PDP11.OPREG.MASK;
this.pushWord(this.regsGen[reg]);
this.regsGen[reg] = this.getPC();
@ -1883,7 +1883,11 @@ PDP11.opWAIT = function(opCode)
PDP11.opXOR = function(opCode)
{
var reg = (opCode >> PDP11.SRCMODE.SHIFT) & PDP11.OPREG.MASK;
this.updateDstWord(opCode, this.regsGen[reg], PDP11.fnXOR);
/*
* As per the WARNING in readSrcWord(), we must supply a register number rather than a register value,
* which will then be evaluated by updateDstWord() after both the SRC and DST operands have been decoded.
*/
this.updateDstWord(opCode, -reg-1 /* this.regsGen[reg] */, PDP11.fnXOR);
this.nStepCycles -= (this.dstMode? (8 + 1) : (2 + 1) + (this.dstReg == 7? 2 : 0));
};

View file

@ -1352,9 +1352,10 @@ CPUStatePDP11.prototype.trap = function(vector, flag, reason)
this.setPC(newPC);
/*
* DEC's "TRAP TEST" triggers a RESERVED trap with an invalid opcode and the stack deliberately
* set too low, and expects the stack overflow trap to be "sprung" immediately afterward, so we
* only want to "lose interest" in the TRAP flag(s) that were set on entry, not ALL of them.
* DEC's "TRAP TEST" (MAINDEC-11-D0NA-PB) triggers a RESERVED trap with an invalid opcode and the
* stack deliberately set too low, and expects the stack overflow trap to be "sprung" immediately
* afterward, so we only want to "lose interest" in the TRAP flag(s) that were set on entry, not ALL
* of them.
*
* this.opFlags &= ~PDP11.OPFLAG.TRAP_MASK; // lose interest in traps after an abort
*
@ -2227,7 +2228,7 @@ CPUStatePDP11.prototype.readSrcByte = function(opCode)
* been decoded and any pre-decrement or post-increment operations affecting the SRC register have
* been completed.
*
* Here's an example from DEC's "TRAP TEST":
* Here's an example from DEC's "TRAP TEST" (MAINDEC-11-D0NA-PB):
*
* 007200: 012700 006340 MOV #6340,R0
* 007204: 010020 MOV R0,(R0)+