Subtle different behaviors between the CPU emulator and the proposed CPU design

[Chalermsak]

I've completed chapter 5 successfully and now I am reading chap 6. Now, to my surprise, I know that an instruction such as

                D=D+A;JEQ

is also acceptable to the assembler and the Hack CPU as well.  Then by chance (and also by my dark side ;) I happen to discover a subtle difference in effect between the CPU emulator and the proposed CPU design (fig 5.9 in the book). I invented a simple program to show this discrepancy as follows:

                @3
                D=A
                A=D-A;JEQ
                @3
                0;JMP

Executing this program with the CPU emulator renders the PC to have the successive values 0, 1, 2, 0, 1, 2, ... (an infinite loop) while executing this program by the computer.hdl on the Hardware Simulator (using the CPU design in fig 5.9) renders the PC to have the successive values 0, 1, 2, 3, 4, 3, 4, 3, 4, ... (a different infinite loop).

This bewildered me for many days until I finally knew why. The 3rd instruction will certainly jump but the CPU emulator uses the new value of A (which is 0) while the fig 5.9 CPU uses the old value of A (which is 3) as the output of A is wired directly to the input of PC chip.

Once undertanding this, I've tried successfully to adjust the design a little by adding some more logics upon the wire leading to the PC's input so as to make it behave exactly the same as the CPU emulator.

So I'd like to report this subtle discrepancy here. Although the programming situations that would yield this discrepancy should be extremely rare (so it may not be that important) but the discrepancy is always there nonetheless.

[WBahn]

Sorry for the late reply. I saw this the day you posted it but didn't have access to the N2T tools at the time. It then fell off my radar.

I've confirmed the bug that you are seeing and will report it to the authors. Hopefully they will fix it in the current version of the simulator and verify that it doesn't exist in the version for the new edition of the text (which is now available for pre-order on Amazon).

I'll pass along what, if anything, I hear.

[WBahn]

I heard back from the authors and they've also confirmed the bug and are very appreciative for you finding it and pointing it out.

The new software will be sure to be consistent with the specs -- namely the jump destination address will be the prior value stored in the A register.

It sounds like there are no plans to upgrade the old software, which is understandably a lower priority at this point. I imagine that a bug report will sit there and perhaps get fixed eventually.

[Chalermsak]

Thank you very much.

[dolomiti7]

Hi,
I fixed the bug myself. My implementations are using heavily A=0;JMP type of commands, so it was a bit annoying that the original CPU emulator didn't execute this correctly.
It is just a trivial change in the CPU.java file of the emulator, switching 2 lines:

computeExp(instruction);
pcChanged = checkJump(instruction); // must be before set destination!
setDestination(instruction); // was previously set before PC update

You can compile it yourself or just replace the Simulators.jar in the tools/bin/lib folder.

Changed source file: CPU.java

Hope that helps
Axel

[pesco]

WBahn wrote

The new software will be sure to be consistent with the specs -- namely the jump destination address will be the prior value stored in the A register.

Has this new software been released? The bug is still in the software I just downloaded from the homepage, which reports itself as "CPU Emulator, Version 2.5" (even though the homepage claims version 2.6).

A bit disappointing to see this not fixed after more than two years, especially given that it's a two-line change.

It might still be worth noting (more prominently) to the OP and future readers that it is the CPU emulator that is misbehaving, not your hardware. The hardware description in the book (figure 5.9) makes it pretty clear what should be happening. The correct jump destination is the value of A at the start of the instruction, before any writes occur.

I made a test script to check for the expected behavior. The program should "stick" to PC=0 for one instruction and not reach PC=1 before time step 2.

dest.asm:

A=1;JMP
0;JMP

dest.tst:

// test jump semantics of the CPU emulator
// writing to A in a jump instruction should not affect the destination

load dest.asm,
output-file dest.out,
compare-to dest.cmp,
output-list time%S1.5.1 PC%D1.5.1 A%D1.5.1 D%D1.5.1;

output;
repeat 3 {
	ticktock;
	output;
}

dest.cmp:

| time  |  PC   |   A   |   D   |
| 0     |     0 |     0 |     0 |
| 1     |     0 |     1 |     0 |
| 2     |     1 |     1 |     0 |
| 3     |     1 |     1 |     0 |

[WBahn]

I don't know what the current plans are regarding the tool chain. It has been some time since I've had any exchanges with the authors. My understanding is that someone else has been developing a completely new set of tools. Those efforts may have hit a snag for any of a variety of reasons. While the delay is unfortunate, it is all-but inevitable given that the number of people involved in maintaining the product can probably be counted on one hand, all of whom have many other higher-priority responsibilities.

I'll try to ping the authors on this, but I, too, have a lot of higher-priority things on my plate.

[pesco]

Sorry, that might have come across a bit rude, my apologies. Still it is unfortunate to have bugs linger.

In the meantime, while the test script I posted above is helpful to verify the CPU emulator, students will be better served with a corresponding test for their hardware. Here is a patch (in unified diff format) that adds one to CPU.tst and CPU.cmp of project 5.

cpu-dest-tst.diff:

diff -u old/CPU.cmp new/CPU.cmp
--- old/CPU.cmp	Mon Oct 10 19:13:26 2022
+++ new/CPU.cmp	Mon Oct 10 19:13:47 2022
@@ -91,7 +91,9 @@
 |45  | 11111|1110001100000110|  0  |*******|   0   | 1000| 1001|      1 |
 |45+ | 11111|1110001100000111|  0  |*******|   0   | 1000| 1001|      1 |
 |46  | 11111|1110001100000111|  0  |*******|   0   | 1000| 1000|      1 |
-|46+ | 11111|1110001100000111|  1  |*******|   0   | 1000| 1000|      1 |
-|47  | 11111|1110001100000111|  1  |*******|   0   | 1000|    0|      1 |
-|47+ | 11111|0111111111111111|  0  |*******|   0   | 1000|    0|      1 |
-|48  | 11111|0111111111111111|  0  |*******|   0   |32767|    1|      1 |
+|46+ | 11111|1110101010100111|  0  |*******|   0   | 1000| 1000|      1 |
+|47  | 11111|1110101010100111|  0  |*******|   0   |    0| 1000|      1 |
+|47+ | 11111|1110101010100111|  1  |*******|   0   |    0| 1000|      1 |
+|48  | 11111|1110101010100111|  1  |*******|   0   |    0|    0|      1 |
+|48+ | 11111|0111111111111111|  0  |*******|   0   |    0|    0|      1 |
+|49  | 11111|0111111111111111|  0  |*******|   0   |32767|    1|      1 |
diff -u old/CPU.tst new/CPU.tst
--- old/CPU.tst	Mon Oct 10 19:13:26 2022
+++ new/CPU.tst	Mon Oct 10 19:13:47 2022
@@ -148,6 +148,9 @@
 set instruction %B1110001100000111, // D;JMP
 tick, output, tock, output;
 
+set instruction %B1110101010100111, // A=0;JMP
+tick, output, tock, output;
+
 set reset 1;
 tick, output, tock, output;
 

PS: The reason I stumbled across this bug is because I made the same mistake in my own implementation of a Hack emulator, which I might make a separate post about. After fixing it, it occured to me to test the "official" emulator, because the bug is subtle. And here we are. :)

[WBahn]

No apologies needed. You didn't come off as rude and I completely understand the frustration.

[dolomiti7]

Nice testfile. I confirm that it works as expected with the patched Simulators.jar file as posted above.