You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you very much for making these tests available. They have really helped to improve the compatibility of my CPU core emulation.
Unfortunately, I have had to disable the MOVE.b and MOVEP.x tests in my testing setup. This is because they list memory addresses in the final state that are not written to during the test.
For example: "051 MOVE.b D3, (A4) 1883" with A4=9FADF190 lists address-value pairs 00ADF190 = $DD and 00ADF191 = $00 in the final state. However, this instruction does not write to byte address 00ADF191, it only touches 00ADF190
My framework assumes that if a memory address is listed in the output then it is of significance. If it does not have an initial value, but does have a final value, the test framework demands that the final value should be written with the given value.
This could be fixed in data two ways:
Remove 00ADF191 = $00 from the final state
Also list 00ADF191 = $00 in the initial state.
seems like the minimal correct set of test data. However, 2 might be more comprehensive, because it tests that the byte write does not affect the following byte of the destination word. However, if this is the purpose then it might be better to add non-zero 00ADF191 values to both initial and final state, and possibly values for the preceding byte too! Perhaps this is getting out of scope of the tests and 1 is actually the better solution.
There is a similar situation with the MOVEP.x tests: the untouched bytes in the words are listed as zero in the final state, but not
in the initial state.
I could add some workarounds to still allow me to run these tests, but it would be great if they could be fixed in data.
Thanks again!
The text was updated successfully, but these errors were encountered:
Hi, I just used this test dataset, and the solution to this problem is to initialize everything, including memory, before starting the test with each instruction. Also, you'll notice that the extra address is actually used by the previous instruction.
Finally, I apologize for my poor English.
Thank you very much for making these tests available. They have really helped to improve the compatibility of my CPU core emulation.
Unfortunately, I have had to disable the MOVE.b and MOVEP.x tests in my testing setup. This is because they list memory addresses in the final state that are not written to during the test.
For example: "051 MOVE.b D3, (A4) 1883" with A4=9FADF190 lists address-value pairs 00ADF190 = $DD and 00ADF191 = $00 in the final state. However, this instruction does not write to byte address 00ADF191, it only touches 00ADF190
My framework assumes that if a memory address is listed in the output then it is of significance. If it does not have an initial value, but does have a final value, the test framework demands that the final value should be written with the given value.
This could be fixed in data two ways:
Remove 00ADF191 = $00 from the final state
Also list 00ADF191 = $00 in the initial state.
seems like the minimal correct set of test data. However, 2 might be more comprehensive, because it tests that the byte write does not affect the following byte of the destination word. However, if this is the purpose then it might be better to add non-zero 00ADF191 values to both initial and final state, and possibly values for the preceding byte too! Perhaps this is getting out of scope of the tests and 1 is actually the better solution.
There is a similar situation with the MOVEP.x tests: the untouched bytes in the words are listed as zero in the final state, but not
in the initial state.
I could add some workarounds to still allow me to run these tests, but it would be great if they could be fixed in data.
Thanks again!
The text was updated successfully, but these errors were encountered: