Closed ISSOtm closed 5 years ago
Considering several solutions for this none of which is satisfying.
I could just remove the orAny macro (and its cousins andAny and xorAny) altogether, since the behaviour can be misleading, but I think it still has value.
I could remove the special case and document the fact that it will be inefficient if comparing something to itself. I don't favour this. I have a feeling that it's more likely orAny will be used outside of the cases mentioned so decreasing the risk of unnecessary cycles would still be an improvement.
I could keep the special case and document when NOT to use it. This seems ok, but documentation can be easily missed or ignored.
I could keep the special case and document it along with a WARN message. This would make it much more likely to be seen, but would pepper working code with warnings and that's not great. Still I think this is what I'll go with for now. I could even write a subsystem to suppress understood warnings, given my tendency to over-engineer.
Have added a warning message to these and provided a config setting to suppress warnings.
This line makes
orAny [hl], [hl]
only read from memory once, which is not expected behavior. This could be useful for reading STAT, for example, or acknowledging by polling memory (some mappers, including custom, work this way)