An interesting puzzle. It feels to me like the tail of the routine should look like

and we should branch into the appropriate part depending on the trailing zeros we find.

Of course I haven't tested this... and it feels like DEC A should be easier than that.

I'm a bit surprised that a 32 bit parameter isn't passed in a soft stack (or a zero page register) - is breaking it into 3 pieces turning out generally to be a good tactic?

I think that keeping the low 16 bits of "TOS" in X:A with Y as a helper should be a win in speed, but the resultant code generated probably looks a bit less straightforward to a typical human observer, and it's probably not more space-efficient than the strategy of keeping all of TOS in RAM, due to register spilling and filling. A clever compiler can minimize the spilling and filling based on the surrounding context, for a net win there as well in many cases.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

From the POV of our backend, A, X, Y, and a region of the ZP are all 8-bit processor registers, so it's not that we're treating A and X as a cache for the stack, but that we're using a modern register based calling convention. It's fairly typical for wide arguments to be split across registers in this fashion in RISC calling conventions

There's still a question of whether or not A and X should be used to pass arguments. The downside I've seen is that it's rare in functions with a lot of arguments that the first bytes are the ones you want in A and X, so they're immediately copied to other registers. The upside is that for functions with small amounts of arguments, it's rather likely that you want them in A and X, since it's the most interesting thing to operate on.

There's a lot of variants we could try; just X, X and Y, just A, etc. Once the compiler has better output, I'm planning to whip up a bunch of different varieties and benchmark them all.

Sounds great!

Alas, these results appear to have been quite fragile. Our nightly verification run caught an issue with G_SELECT lowering, and fixing it slightly changes the order in which selects are lowered, which turns the decrement sequence to mush.

The gist of the problem is this: on the 6502, a huge number of operation types can only be efficiently computed using a sequence of branches. We need to introduce these branches before scheduling instructions, since branching produces control flow regions that don't share register pressure; for example, A can have different values on each side of the branch.

However, the branches *themselves* also need to be scheduled, since LLVM isn't capable of moving instructions across a branch! So what's happening is that we're introducing branches really early in the pipeline on essentially unordered generic machine code. LLVM can't move instructions across these cuts, so whatever randomly happened to be on one side stays on one side. That means that any values that are live across the branch stay live across the branch, even if moving an instruction across could shorten the live range to zero. This means that there are a lot more values that the register allocator has to keep live at any given point in the program, which produces a bogus overall compile.

So, we need to run a scheduling pass *before* we introduce branches to make sure that instructions are on the right side of them. Since we can nest branches in branches, we also have to run this scheduling after branches are lowered and instructions are sunk into each side. So the scheduling needs to be a part of the G_SELECT lowering, interleaved with it.

This'll be a fairly major project to fix, but it's becoming apparent that G_SELECT lowering is the single most important part of the backend. The answer to how do I XX on the 6502 apparently always involves a tricky sequence of branches of one form or another.

Yeah, the fastest 6502 code seems to be more branch-heavy than the more sophisticated processors because 6502 branches are so efficient. If you want to introduce a branch-less template for this task, maybe you could just teach it:and get back to the challenge (of speeding it up) later.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

That's actually the sequence it was using before the latest work; but intrinsic in using the INC and DEC instructions for >1 byte is a facility with branching.

But the compiler can get worse before it gets better; that's the biggest reason why I'm doing all this work before a v1 release, since at that point it'll actually be a problem if performance regresses.
Better to speak INC and DEC poorly than not at all; at least that way the code is continuously being exercised and not bit-rotting.

I like that Mike! Addition or subtraction with a short constant simpler than increment or decrement.

Simpler and more versatile, but certainly not the best on clock ticks in the general case.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Is it the case that LLVM needs to discover (or re-invent) sequences like these, or is it seeded with handy routines that it can later rejig according to surrounding code?

The answer is somewhere in between. Our backend doesn't really have anything resembling real 6502 assembly until really really late in the compilation process, one or two passes before the final machine code is generated. All of the work of the compiler occurs on internal representations that very very gradually come to resemble 6502 assembly. So we can teach LLVM generic patterns, but it's difficult to teach it flat instruction sequences.

WARNING: A way-too-detailed look at what LLVM is doing follows.

The code that LLVM sees starts nearly as vague and high level as C; each LLVM pass either makes the sequence faster or makes the sequence more specific.
The advantage to doing things this way is that you avoid needing to go back and correct poor decisions later; instead the compiler attempts to avoid making decisions at all until a point where those decisions are relatively clear. This can't be done perfectly, but there's also hard limits to how many bad decisions you can clean up at the end.

For example, the DEC function under discussion starts out as:



The calling convention is implemented:



Now, there are operations in here you can't natively do on the 6502: a 32-bit decrement. These are replaced with sequences that can plausibly be performed on the 6502 (legalization):



This is the pattern that I mentioned for decrementing: always decrement the low byte, and decrement the high bytes if and only if the low byte was previously zero.

G_SELECT is like a C ternary: G_SELECT %61, %62, %4 = %62 if %61, otherwise %4.
G_SBC is a generalized SBC operation: it provides an output and all the possible flags, and takes two arguments and a carry in. Depending on what's used, this covers the behavior of the various comparison and subtraction instructions.

Note that at this phase, we haven't picked instructions, what registers things are going to go into, anything like that at all. Just the basic plan of how it's going to decrement exists.

From there, we lower the G_SELECT instructions to (still totally generic) branches.
EDIT: Surprisingly, the lowering below looks alright to me. I'm either missing something, or the problem actually lies elsewhere...



From this, we select idealized versions of the 6502 instructions to use. These still aren't actual 6502 opcodes, but they capture the kinds of constraints that exist on the 6502 about where you can put things: for example, you can only natively compare when the LHS is A, X, or Y, but not an imaginary register, and the rhs has to either be an immediate or an imaginary register.



Note that at this stage, LLVM still hasn't decided where to put anything! DEC instructions are generalized: they can operate on A, X, Y, or any ZP register. The A variant uses CLC ADC; and will later use DEC A on the 65C02.

And then, much much later, after a ton of additional manipulations, LLVM allocates registers and decides where to put everything:

Thanks for the explanation! Of course I only skimmed it, but it'll be good to come back to.

It's really encouraging that LLVM can tackle this problem even reasonably well. I'm very grateful that you're doing the work to make it real!

It looks like the bad compile was actually caused by the register allocator; needing to keep the original operands alive was quite a challenge.

But there's an easy way to reduce the pressure on the register allocator: compare the result of the decrement with 255 rather than comparing the argument with zero. This isn't optimal, since it prevents the comparisons from ever being folded away. Immediate compares are pretty quick and pretty small though, and the spill code required to keep the arguments alive can apparently be more than that in the worst case.

With that, the sequence is now:

Optimization work is progressing steadily, but slowly.

As always, "low-hanging fruit" turns out to take 10 times as long as I've estimated.

Still, there's some new stuff!

Standard library call optimizations
LLVM has now been told that our standard library function behave as C standard library functions should. This allows it to, for example, rewrite "printf("Hello, world!")" to "puts("Hello, world!")". This is actually a pretty major optimization; it's common C programmer practice to printf things they should puts (especially while debugging), and LLVM is already capable of inlining the puts.

Better loop optimization
I've mostly taught LLVM about the 6502's addressing modes, which required significantly extending a key LLVM optimization pass. LLVM will now attempt to narrow variables that vary with the loop ("induction variables") to 8-bits wherever possible, zero-extending them to wider types if necessary. Zero-extending is "free" on the 6502, so that's a good tradeoff. This code is deeply immature and imperfect though; it's clear I'm going to have to keep hammering on it throughout the life of the project.

Switch Jump Tables
LLVM now lowers switch statements to jump tables where appropriate. Depending on how the cases are laid out, it may do a binary search to narrow the cases, then several jump tables for cases that are clustered together.

The jump tables are separated into two arrays in classic 6502 fashion: first all the low bytes, then all the high bytes. The size of each array is limited to 256, guaranteeing lookup using the absolute indexed addressing mode.

We're not using the RTS trick at the moment; it's a speed/size tradeoff (4 bytes smaller, 1 byte slower), and it's slightly more complicated to code in LLVM. Instead, we indirect JMP through a zero-page pointer, which also handily works around the NMOS indirect jump bug.

Computed Goto
On the way to the above, we've also enabled GCC's computed goto extension. You can take the address of C labels, stash them away as pointers, and call them via a special goto syntax. This turns into an indirect jump, just like switch lowering.

Hello, world!
The first two optimizations bring a return to form for the essential "Hello, world" example:





Until next time!

Awesome. It sounds like you're making a lot of progress. I am reading this correctly that ".LBB0_1" is the start of loop for the inlined puts implementation and "jsr 65490" is the call to a subroutine that actually outputs the character?