And support for the `#[naked]` attribute will likely be stabilizing within the next few months (source: I'm getting sponsored to work on it), allowing one to write functions that have precise control over the stack, which is useful for interrupt handlers.
Don't you want "interrupt ABIs" for that specific usecase?
IIRC `#[naked]` are only really guaranteed to allow inline assembly, so it's like defining a function in `global_asm!` except for monomorphization and generally interfacing better with the rest of the language.
I'm not aware of any proposal for interrupt ABIs, but in the meantime naked functions essentially allow you to create ad-hoc interruput ABIs. Do you have a link?
(That said you're right that naked functions still have a place for doing this, I can't imagine the compiler would grow stable support for every random ABI someone could come up with. But for more well-known ones it's a nice thing.)
It's a shame LLVM isn't more explicit about calling conventions (especially since the front-end has to lower most of the platform-specific C ABI details, short of the exact list of registers or stack offsets, into LLVM IR anyway).
(if it was more expressive, we could have e.g. specifiers similar to inline `asm!`, but on a function signature, to fully describe its call ABI)
In the meanwhile, I agree - if you need some entry-point to have a custom ABI (especially if you need it parameterized through generics), `#[naked]` + inline `asm!` is the only viable option for now.
Especially with const generics, you can do some cool stuff to make very compact trampolines that e.g. embed immediates directly into instructions (though it's sad that `const` operands in inline `asm!` aren't stable yet).
But for interrupt ABIs I would hope that LLVM can fully support them and avoid any inefficiencies that "whole body is one inline `asm!`" could create by blocking LLVM from doing optimizations, clever register allocation, etc.
(that is, they let the user control when they do something special with inline `asm!` vs regular code that LLVM understands)
So asm! is basically the same functionality, except it's been stripped down to features that are more easily verified for correctness, and some of the syntax has been tweaked to be more understandable. The original asm! macro just passed everything through to the LLVM inline asm construct in raw form, and was renamed llvm_asm! to allow people to keep compatibility while the cleaned-up version of asm! was worked on.
I think the biggest missing features are the more exotic, non-register constraints, but some of the reasons those are omitted are because of unclear coordination between Rust code and the assembly language string.
Can you give more specifics? Backend-wise, the new asm support is still using LLVM's assembly facilities, so it should be just as capable. As far as the user-facing portion is concerned, some features of the `asm!` macro are still unstable (most notably const operands and sym operands), but I'm not aware of any feature that doesn't have an equivalent.
