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
{{ message }}
This repository has been archived by the owner on May 15, 2024. It is now read-only.
There are a lot of rare edge cases in 65816 that depend on an address being XXFF or FFFF and then adding an offset. For example, an operand might be at address 0x6BFFFF with the high byte on 0x6BFFFF+1.
They are handled in different ways. 0x6BFFFF+1 could become 0x6B0000, 0x6BFF00, or carry into the bank (6B): 0x6C0000.
Because of how rare this cases is, it simply isn’t tested in most tests, so both 0x6B0000 and 0x6C0000 implementations pass and it is impossible to know which is correct.
Either more tests need to be generated to be sure these edge cases are covered or some percentage of 10,000 tests should be biased toward (or guaranteed to be) these edges cases.
The text was updated successfully, but these errors were encountered:
There are a lot of rare edge cases in 65816 that depend on an address being XXFF or FFFF and then adding an offset. For example, an operand might be at address
0x6BFFFF
with the high byte on0x6BFFFF+1
.They are handled in different ways.
0x6BFFFF+1
could become0x6B0000
,0x6BFF00
, or carry into the bank (6B):0x6C0000
.Because of how rare this cases is, it simply isn’t tested in most tests, so both
0x6B0000
and0x6C0000
implementations pass and it is impossible to know which is correct.Either more tests need to be generated to be sure these edge cases are covered or some percentage of 10,000 tests should be biased toward (or guaranteed to be) these edges cases.
The text was updated successfully, but these errors were encountered: