Although x86 still holds the vast majority of market share over most desktop platforms, sales of desktops and laptops in general are quickly declining while sales of devices such as tablets and smartphones are on the rise. What's more, many system vendors, notably Apple and Qualcomm, are starting to use ARM chips in desktop-class hardware to boot. For this reason, in addition to x86-interrupt which already exists, at least the following similar ABIs are needed:
extern "apple-silicon-interrupt"
extern "snapdragon-interrupt"
extern "exynos-interrupt"
extern "tensor-interrupt"
extern "tegra-interrupt"
Granted, the implementation of some of these is definitely easier said than done, but given how quickly the popularity of the ARM architecture in general is on the rise, this definitely needs consideration.
Are these actually separate interrupt ABIs? I understand Apple likes to do things differently, but do you have a source that, say exynos and tensor are different? Or that any of these are different from the Arm standard?
Part of me wonders whether function call ABIs could be extensible so as not to require baked-in support within the compiler for every conceivable esoteric possibility.
We could decide to support arbitrary interrupt ABIs by requiring people to use naked functions and inline assembly. I'm not sure we want to do that, though.
You could do this with global asm today I assume? Have a global asm block that does the required preamble, calls a rust function (with extern C ABI probably?) then does any required cleanup to return from the interrupt.
As explained in the RFC, there's a performance penalty when using inline assembly instead of interrupt ABI because all registers need to be backed up (not just the ones that will be overwritten). So some sort of language support is required not only for usability, but also for performance.
One alternative proposed in the RFC is a "preserve-all" calling convention that preserves the contents of all CPU (and FPU, SSE, etc) registers. With such a calling convention, we would only need a small assembly wrapper to handle the platform-specific things (e.g. returning using the iretq instructions on x86_64). Such a "preserve-all" calling convention could be platform-independent and thus require less maintainance than a full set of interrupt ABIs.