Get llvm test-suite running and compatible with llvm-mos

[mysterymath]

As much of the llvm test-suite as we can run as-is should be made to do so against a 6502 simulator. This work will help to establish what's required to hook this up.

[mysterymath]

Quickest way to get >0 of the tests passing:

• Select off the shelf 6502 simulator and incorporate into SDK. The simulator should have a feature to allow a memory access or JSR to output a byte to stdout. A target configuration should be created for the simulator with a _putchar function.
• Implement just enough of the code generator to get mpaland's minimal printf working with the above _putchar, without floats or long longs.
• Plumb the simulator through the emulator mechanism in llvm-test-suite. See if we can at least get a couple of the tests passing.

[johnwbyrd]

Keep in mind that the problem is bigger than just simulating a 6502. There's a family of processors with slightly different behaviors that will eventually need to be simulated. And eventually we'll need gdb remote debugging and a bunch of other stuff.

I'm sketching out the structure of an LLVM-internal emulator in github.com/johnwbyrd/llvm-mos, in the feature/emulator branch. When it does more than take up disk space, I'll push it into the main repository.

If you are gated without an emulator, I suggest https://www.piumarta.com/software/lib6502/ , which will at least get you up and running.

[mysterymath]

Ah neat, lib6502 was one of the ones on my shortlist.
Part of me wants to use https://github.com/mist64/perfect6502, since it's a transistor-level simulation from the visual6502 project. It's supposed to be pretty dog slow, but that might not matter for the kinds of tests we're likely to run.

It's worth noting that 6502 variant desirability follows a bit of a power law. The stock NMOS 6502 core was used in roughly double the number of systems as the CMOS version, which was used in roughly double the number of systems as the 65816.

The 65816 is sufficiently different from the 6502 that it probably wouldn't be able to share much code with the 6502 code generator. The most direct analogy I can think of is comparing a hypothetical backwards compatible version of the 16-bit 8086 with the original 8-bit 8080/Z80. It's very unlikely that a good code generation approach for the 8086 would look anything like one for the Z80; the problem space is too different.

The CMOS variant I'd consider fairly near-term future, since it's not at all like that. Same with the illegal opcodes, if there's any plausible use for them in the instruction selector. But the 816 would probably come along after all's basically said and done, and I'll probably have moved on to greener pastures by then.

[mysterymath]

Update:
The minimal printf.c in the SDK can now make it about half way through the code generator, stalling in register allocation. Haven't yet started debugging that; it looks like there are several potentially unrelated problems.

One of them is that the call sequence emits arguments left to right; so A, X, and Y are immediately tied up. This prevents them from being usable to fulfill the other ZP arguments of the call. The machine scheduler should take care of this, since the problem is essentially that the register pressure on GPR is way higher than 3; I've no idea why it's keeping the original order. Investigation pending.

[mysterymath]

A suitable re-tuning of physical register use in the instruction scheduler has brought printf.c through register allocation, crashing now in prolog/epilogue insertion. Onward and upward!

[mysterymath]

Printf.c now can make it all the way through to final assembly output. I'm now shifting to work on the SDK side of things; there's quite a few constructs and pseudos that need to be there for printf to have a chance of working.

[mysterymath]

I've added a llvm-test-suite subproject containing the required changes to the upstream LLVM test suite to allow at least a few small SingleSource examples to compile, link, and run under the simulator provided with the SDK. I haven't found any test suite cases that actually work yet, but they do seem to run, so this issue is finished.

Now we can start the real meat and potatoes of getting these test cases to pass. It looks like the GCC torture suite will be our best friend for this; the examples are very small and self contained, and quite thoroughly exercise the compiler's semantics. Accordingly, I've enabled it for ARCH=MOS in the test suite's CMake.

[johnwbyrd]

Good to see that this works as expected. I'd like to get llvm-test-suite running with a github runner, triggered whenever llvm-mos gets a checkin, and have the latest results posted automatically somewhere prominent.