How do you handle arbitration between spilling call-preserved registers on the stack and the creation of new functions?

The way I see that, and I may be severely wrong: once I filled all the called-preserved registers, I would spill on the stack, but if I end up spilling on the stack all call-preserved regs, I do create new functions.

I don't use register spill as a criterion for creating functions.

If I use some non-trivial code more than once then I will consider making it a function.

The final call will be made based upon what I need to optimise for. If I need peak performance then I will benchmark each way to decide. If I want good readability then I usually just make a new function. If I need to move on quickly to meet a deadline then I often just copy/paste with the (often unmet) hope to come back later to "fix" it.

Indeed, the "trivial and more than once" usually does pre-empt spilling leading to function creation, that upon initial coding.

The functions I am talking about would have very probably only one call-site (ooof) and would be non-trivial (their state would eat a good part of call-preserved regs since many would perform ABI calls).

I guess I should eat the bullet: handle such huge code path with reg spilling all over the place. I should start to figure out a not too disgusting way to handle deeply nested labels (here, I use a basic C pre-processor).

My computer science professor called it cohesion and containment. Is the function cohesive - does it do one thing well and not anything else? Is the function contained - not linked to many external things? If those things are true then you have a good function.

As we scale to greater complexity we're asking the questions at a complexity scale. This is systems thinking.

* disclaimer: that's advice from the late 80's.

I am talking sorta more about ABI functions.

In C and similar, we write more 'logical' functions than ABI functions.

In assembly, many C functions would end up as just some code blocks.

In the end, with now more perspective, I write ABI functions in assembly for flexibility mostly since I am in the middle of the development cycle: program structure is far from being stable.

Once program structure does settle down, some ABI functions will probably move as 'code block' functions: both are 'logical' functions following the guidelines you talked about.

Early in development I stay with the "systems thinking" - just at a low level. We can use macros to abstract out the registers: These are just puzzle pieces in the low-level, or pseudo-instructions. It's not unusual to make macros with the operand support tags from the manuals: r32, rm32, ... It takes some work to make them very general, but extremely reusable.

The nice thing about systems thinking is that it always works at the level one is working. If it didn't then it wouldn't be system thinking.