Revise `[bp + 0]` effective address cycles from 5 to 9 in listing 56?

[Michael Hinton]

In Q+A 21 for question [00:13], you reviewed the microcode and concluded (at around [25:40]) that a displacement of 0 would still go through the motions in an effective address calculation, and thus take 9 cycles instead of 5. Were you planning on changing listing 56 to reflect this (and I guess your simulator as well)?

So

computer_enhance/perfaware/part1/listing_0056_estimating_cycles.txt

Line 18 in 15e0e7b

 mov cx, [bp] ; Clocks: +13 = 62 (8 + 5ea) | ip:0x17->0x1a 
 

should really be

mov cx, [bp] ; Clocks: +17 = 66 (8 + 9ea) | ip:0x17->0x1a 

and

computer_enhance/perfaware/part1/listing_0056_estimating_cycles.txt

Line 55 in 15e0e7b

 mov cx, [bp] ; Clocks: +17 = 74 (8 + 5ea + 4p) | ip:0x17->0x1a
 

should really be

mov cx, [bp] ; Clocks: +21 = 78 (8 + 9ea + 4p) | ip:0x17->0x1a

I bring this up because in order to satisfy the listings as they currently are in my simulator code, I had to add extra logic to check if the displacement value was 0, and if so, discard the displacement cycles.

It seems to me that perhaps the reference simulator treats a displacement of 0 and 'no displacement' as the same thing due to the if check simply checking that the value is not 0 rather than checking for existence. Perhaps this is the only reason why the reference simulator showed 5 cycles instead of 9 in the first place:

computer_enhance/perfaware/sim86/sim86_cycles.cpp

Lines 65 to 68 in 15e0e7b

 if(Expr.Displacement) 
 { 
     Result += 4; 
 } 

I'm fine with "correct, but won't fix," but I just wanted to point this out in case others got confused like I did, and to verify that I'm understanding this correctly.