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

Extraneous memory values in final state for MOVE.b and MOVEP.x tests #1

Open
howprice opened this issue Jan 14, 2025 · 1 comment
Open

Comments

@howprice
Copy link

howprice commented Jan 14, 2025

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:

  1. Remove 00ADF191 = $00 from the final state

  2. Also list 00ADF191 = $00 in the initial state.

  3. 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!

@chip-64bit
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants