Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test warrior gives different result from pMARS #42

Closed
aerkiaga opened this issue Aug 8, 2020 · 9 comments
Closed

Test warrior gives different result from pMARS #42

aerkiaga opened this issue Aug 8, 2020 · 9 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@aerkiaga
Copy link
Owner

aerkiaga commented Aug 8, 2020

This warrior loses on pMARS, ties on hMARS on the first round. Could be P-space-related. See #41.

       ORG      START
START  SPL.B  $    16, #     0     
       DJN.B  $     0, #   100     
       ADD.F  }    -2, $    -1     
       DJN.B  $    -1, #    16     
       ADD.AB $    -3, $    -3     
       MOD.AB #     2, $    -4     
       JMZ.B  $    34, $    -5     
       JMP.B  #     0, #     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       STP.BA }    -8, @     3     
       SEQ.BA $    -2, #     1     
       MUL.A  #     2, $     8     
       DJN.F  $     7, {    -4     
       DAT.F  {     6, }    -1     
       SLT.A  $     4, >     0     
       NOP.A  @    -8, >    -3     
       LDP.F  }    -8, }     8     
       ADD.BA <    -2, {    -4     
       NOP.BA @     5, *     5     
       STP.BA $     4, }    -8     
       JMP.BA >    -6, <    -2     
       NOP.BA >    -2, #    -8     
       DIV.BA <     0, *     2     
       SNE.AB #     1, #    -4     
       JMN.X  *    -2, >     2     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       DAT.F  $     0, $     0     
       MOV.I  $   -32, $   -24     
       JMP.B  $    -1, >    -1
@aerkiaga aerkiaga self-assigned this Aug 8, 2020
@aerkiaga aerkiaga added the bug Something isn't working label Aug 8, 2020
@aerkiaga aerkiaga added this to the 0.3 milestone Aug 8, 2020
@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 8, 2020

From #41:

Trace of test warrior up to end of test code execution, comparison between pMARS and hMARS:

SPL.B $16, #0
DJN.B $0, #100
STP.BA }-8, @3
DJN.B $0, #99
SEQ.BA $-2, #1
DJN.B $0, #98
MUL.A #2, $8
DJN.B $0, #97
DJN.F $7, {-4
DJN.B $0, #96
STP.BA $8, }-8
DJN.B $0, #95
JMP.BA >-6, <-2
DJN.B $0, #94
SLT.A $4, >1
DJN.B $0, #93
LDP.F }-8, }8
DJN.B $0, #92
ADD.BA <-2, {-4
DJN.B $0, #91
NOP.BA @1, *4
DJN.B $0, #90
STP.BA $8, }-8
DJN.B $0, #89
JMP.BA >-6, <-2
DJN.B $0, #88
NOP.A @-8, >-3
DJN.B $0, #87
LDP.F }-8, }8
DJN.B $0, #86
ADD.BA <-2, {-4
DJN.B $0, #85
NOP.BA @1, *3
DJN.B $0, #84
STP.BA $8, }-8
DJN.B $0, #83
JMP.BA >-6, <-2
DJN.B $0, #82
LDP.F }-8, }8
DJN.B $0, #81
ADD.BA <6, {-4
DJN.B $0, #80
NOP.BA @1, *2
DJN.B $0, #79
STP.BA $8, }-8
DJN.B $0, #78
JMP.BA >-6, <-2
DJN.B $0, #77
ADD.BA <6, {-4
DJN.B $0, #76
NOP.BA @1, *1
DJN.B $0, #75
STP.BA $8, }-8
DJN.B $0, #74
JMP.BA >-6, <-2
DJN.B $0, #73
NOP.BA @1, *0
DJN.B $0, #72
STP.BA $8, }-8
DJN.B $0, #71
JMP.BA >-6, <-2
DJN.B $0, #70
STP.BA $8, }-8
DJN.B $0, #69
JMP.BA >-6, <-2
DJN.B $0, #68
JMP.BA >-6, <-2
DJN.B $0, #67
NOP.BA >-2, #-8
DJN.B $0, #66
DIV.BA <0, *0
DJN.B $0, #65
SNE.AB #1, #-2        SNE.AB #1, #-3
DJN.B $0, #64
Nothing               DAT.F $0, $0

Correct               hMARS

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 8, 2020

From #41:

After that SNE executes, the process falls right into a DAT in both cases, pMARS simply ignores it. However, that -2/3 does make a difference. Even though it doesn't alter the course of execution, when the counter process reaches zero and a parity check is performed, the result is different, giving a different round outcome.

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 8, 2020

Confirmed on master

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

This warrior was simulated by hand (read: I simulated). The second execution of LDP.F }-8, }8 sets that initial -4 to the value stored at P-space location 0, i.e. -1. Then, the first execution of ADD.BA <6, {-4 predecrements it to -2, then to -3 on its second execution.

Right before the problematic instruction, DIV.BA <0, *0 executes. This could possibly be the source of the issue. If this instruction, for some reason, incremented the B-field of the one following it, then it would be -2 when ran. Seems unlikely, but an instruction containing two zero fields with indirect addressing and a predecrement is pretty scary standard- and bug-wise.

Another possibility is that P-space position 0 contains 0 rather than -1 in the first round under pMARS. Here's the modified section of the final warrior state after the test process terminates (differences when P-space position 0 is 0 are indicated):

   DAT.F  $    -1, $    -1     
   DAT.F  $     2, $     0     
   STP.BA }    -8, @     3     
   SEQ.BA $    -2, #     1     
   MUL.A  #     9, $     8     
   DJN.F  $     7, {    -3     
   DAT.F  {     2, }    -1     
   SLT.A  $     4, >     8     
   NOP.A  @   -10, >    -4     [A:-10]
   LDP.F  }   -16, }     8     [A:-8]
   ADD.BA <     6, {    -4     
   NOP.BA @     1, *    -3     
   STP.BA $     8, }    -7     
   JMP.BA >    -6, <    -2     
   NOP.BA >    -2, #    -8     
   DIV.BA <     0, *    -1     
   SNE.AB #     1, #    -3     [B:-2]
   JMN.X  *     1, >     0     

Overall, the course of execution is in agreement with hMARS.

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

This testcase:

LDP.AB  #0,        #0
SEQ.AB  #-1,        $-1
JMP.F   #0

shows that pMARS also gets -1 from P-space location 0. Here's a theory:

[0] = 0         < Here's a write to location 0
[6] = 0
x = [-1]
[4] = 0
y = [0]         < Here's a read from location 0
[-8] = 0
z = [3]
[-16] = 0
[6] = 0
[1] = 0
[8] = 0

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

Eureka!

STP.AB  #5,        #0
LDP.AB  #0,        #0
SEQ.AB  #-1,        $-1
JMP.F   #0

Watch this warrior overwrite P-space location 0 with garbage on pMARS! Wasn't it read-only? hMARS treats it differently just to ensure its unwritability. Edit: actually it's to keep that location separate from other warriors that share a P-space via PIN.

@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

  • The beginners' guide to Redcode 1.22: "location 0 is a special read-only location" (RO)

  • Core War FAQ: "It is initialized to a special value before each round" (RW)

  • ICWS '94 Draft 3.3: doesn't even mention P-space (?)

  • The pMARS manual: "pMARS updates P-space cell 0 at the beginning of each round" and "P-cell #0 holding the result of the last round is exempt from sharing" (RW)

Thus seems like the cell should be read/write. There is an error in the Beginners' guide to Redcode, from which the P-space behavior was clarified (due to the standard not stating anything). Will post on the newsgroup for assistance...

aerkiaga added a commit that referenced this issue Aug 9, 2020
Added a switch, `PSPACE0_READ_ONLY`, to get the previous behavior. Must 
still change JIT behavior to respond to the same switch.
@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

Now the self-test fails in the first phase because Classic and JIT do not behave the same. Will have to port these two Classic-only changes to JIT (the first change didn't affect single-round tournaments, so it doesn't affect the testcase; also should add a multi-round testcase).

aerkiaga added a commit that referenced this issue Aug 9, 2020
Now also for JIT. No switch though, it's unnecessary, as it just enables 
a setting that doesn't exist in any specification.
@aerkiaga
Copy link
Owner Author

aerkiaga commented Aug 9, 2020

Now we're passing the pMARS testcase for the first time!

@aerkiaga aerkiaga closed this as completed Aug 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant