Write 65xx simulator about llvm-mos

[mysterymath]

I just remembered that some of the indexed operations will also issue stray reads to totally separate locations; that was a big correctness TODO, since we'd need to make sure again not to use certain indexed operations either for volatile operations.

[johnwbyrd]

Yes, I would hope to see something like llvm-emu --target mos binary-file, with the output checked in lit. This would be the emulator's principal use case.

[johnwbyrd]

Hello, I've been doing some work on an emulator framework for my own 6502 tooling and figured I'd drop a line to see if it could be of any use to y'all.

https://github.com/ncatelli/mainspring/blob/main/examples/microcode_step_capture.rs

Hi ncatelli, your work is interesting but it would to my knowledge be the only bit of Rust associated with this project, and the only tool written in Rust that is associated with LLVM in general. LLVM compiles Rust, but all LLVM tools are written in python or C++.

[ncatelli]

Ahh sorry about that, I saw the repo and was hoping I could save you time on the tedious work emulating opcodes. Again, cool project and thanks for the time.

[mysterymath]

Is this a blocker for end-to-end testing, or can we pull one of the existing simulators/emulators as a dependency for that?

It's not exactly correct to say we have no cycle-accurate issues. There's one that I know of off-hand: the compiler will need to avoid generating RMW operations on NMOS 6502s for volatile pointers. Due to the double-write bug on those processors, the compiler may otherwise accidentally trigger an unintended hardware operation due to the spurious write.

We can test this fairly well in unit tests for the code generator, but that's true for most of the project, really. End-to-end tests are bigger, slower, harder to debug, and harder to write than unit, integration, and diff tests. The main advantage they bring is fidelity to the end use case: they catch "unknown unknowns"; stuff we haven't thought of, but that the emulator/simulator authors did.

[johnwbyrd]

I'd like to understand the RMW bug you're referring to specifically before I respond. Pointers please?

[johnwbyrd]

In any case, what I do needs to admit the future possibility of different emulation techniques (cycle accuracy, per instruction classic emulation, and qemu style dynamic recompilation) as well as the world of 65xx near clones. Again, this sounds nastier than I think it will be. Choice of the right abstractions up front, may make this small work... llvm is already doing like 80% of the heavy lifting involved.

[mysterymath]

Looks like I remembered this a bit wrong too; the CMOS version didn't exactly fix it, it now just does double-reads instead of double writes. From the 6502 Wikipedia page:

The 6502 read-modify-write instructions perform one read and two write cycles. First, the unmodified data that was read is written back, and then the modified data is written. This characteristic may cause issues by twice accessing hardware that acts on a write. This anomaly continued through the entire NMOS line, but was fixed in the CMOS derivatives, in which the processor will do two reads and one write cycle. Defensive programming practice will generally avoid this problem by not executing read/modify/write instructions on hardware registers.

[johnwbyrd]

My current intention is to create a small class library that can be subclassed into an instruction emulator, a cycle exact emulator, JIT, etc. as our requirements grow more demanding. Additionally, it sounds like we may need to create specific emulator variants for testing volatile features, such as a virtual device that increments a particular address on read, and another on write. It may also be useful to create an emulator variant that traps on reads or writes to stray locations. lldb as well has a place to plug in a MOS emulator, when one exists. If base classes and specializations are chosen reasonably, then the result should be a class of related emulators, instead of "the emulator." A hello world type proof of concept is in order.

[johnwbyrd]

The primary use for such an emulator, of course, is part of automated test suites. Even a quick regression test with imperfect emulation is better than nothing.

[jackoalan]

Would the simulator be made to work in conjunction with LIT/FileCheck? So writes to $FFxx simply print a line that can be verified with a CHECK comment?

[johnwbyrd]

This continues, as I find time to work on it. I've added support for emulator libraries, in the same style as Disassembler and AsmParser libraries, within cmake, so that other platforms could theoretically leverage this work in the future.

[ncatelli]

Hello, I've been doing some work on an emulator framework for my own 6502 tooling and figured I'd drop a line to see if it could be of any use to y'all.

https://github.com/ncatelli/mainspring/blob/main/examples/microcode_step_capture.rs

[johnwbyrd]

Perhaps you could help in other ways. You may wish to review the bug list, pick out a few issues, and try writing a few patches.