When I prototype new code paths, I start to write them like I have an infinite amount of registers (no stack spilling ofc).

That way I don't encumber my mind with the register dance yet, namely I am more fluid at coding (a bit more like C).

Once I have a first satisfying "unlimited registers" prototype of the code path, I start to deal with registers, memory spilling and more.

And you guys? Any tips?

All that said I am going to repeat myself: I still have a very strong feeling of freedom while coding assembly. Not being dependent on a compiler feels so much more satisfying than coding C (or anything similar).

I like to make functions/procedures that only need to use the stack to save the callers registers. That is, when it doesn't need local stack variables, it only uses registers. So if it looks like the current code is getting unwieldy I look into how to split it into two more more parts to call independently.

It isn't always possible, but when I can get that it feels satisfying.

However all of that gets ignored in critical code paths. When performance matters a single call/ret overhead might really hurt.

Yeah, this is the register dance I was talking about.

Before that step, prototyping while having an infinite amount of regs is really fluid.

I've been honing a technique using macros. To remove ambiguity, I force all used registers to be passed as parameters. An added complexity is hidden in how the registers are used: read, write, or read-write. Application of the technique sometimes makes this obvious.

Prior I also applied an optimistic allocation of registers with refactoring as needed. The macronization [not a word, implying: replaced fragments with macros] makes it so I do not need to search-and-replace registers as I refactor.