Tracking issue for the msp430-interrupt calling convention/ABI

[japaric]

Added in #38465

This calling convention is used to define interrup handlers on MSP430 microcontrollers. Usage looks like this:

#[no_mangle]
#[link_section = "__interrupt_vector_10"]
pub static TIM0_VECTOR: unsafe extern "msp430-interrupt" fn() = tim0;

unsafe extern "msp430-interrupt" fn tim0() {
  P1OUT.write(0x00);
}

which generates the following assembly:

Disassembly of section __interrupt_vector_10:

0000fff2 <TIM0_VECTOR>:
    fff2:       10 c0           interrupt service routine at 0xc010

Disassembly of section .text:

0000c010 <_ZN3msp4tim017h3193b957fd6a4fd4E>:
    c010:       c2 43 21 00     mov.b   #0,     &0x0021 ;r3 As==00
    c014:       00 13           reti
        ...

cc @alexcrichton @pftbest

[steveklabnik]

Triage: not aware of any movement on stabilizing this.

[cr1901]

@japaric @steveklabnik My understanding is that upstream wants to prevent proliferation of various calling conventions, hence no movement on this.

The "special" calling convention for msp430 is: You must save all registers that you modify (except PC and SR), including call-clobbered registers that are normally temporaries. This to me sounds like a generic "save everything" calling convention. Are you aware of any feature resembling a generic "save everything that was modified" calling convention?

In the interim, I have a plan for allowing interrupts to be done in msp430 using the C ABI, but I don't plan to use it in my code because it has a nontrivial overhead for the smaller parts.

[jonas-schievink]

IMO this should just be stabilized as-is. It seems completely reasonable for a systems programming language to provide support for niche calling conventions in the same manner it supports the C and other "major" calling conventions.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We're willing to consider stabilizing target-specific interrupt calling conventions like this. We feel like this needs an RFC, not specifically for msp430-interrupt but for target-specific interrupt calling conventions in general. See #40180 (comment) for details there. Once such an RFC gets merged, we'd be happy to add conventions like msp430-interrupt given just a patch to the reference.

Also, given the amount of time that has passed, we'd like to confirm with msp430 folks that this is still functional and used.

[cr1901]

@joshtriplett I'm only one user; there are a few ppl besides me. Nowhere near cortex-m, but I can confirm it's still functional and used as of yesterday :).

In the interim, I have a plan for allowing interrupts to be done in msp430 using the C ABI, but I don't plan to use it in my code because it has a nontrivial overhead for the smaller parts.

This never materialized for many reasons, but one of them is admittedly "this functionality is not something I would personally use, and I didn't receive any reports of ppl really wanting to use stable for msp430".

I've been revamping msp430 Rust, and interrupts are still rather useful; the #[interrupt] attribute expands to "msp430-interrupt"

We feel like this needs an RFC, not specifically for msp430-interrupt but for target-specific interrupt calling conventions in general.

This is in line with what I want as well, and I will read the relevant issue to get involved. There are other backends I'd be curious (68k comes to mind immediately :)) to see getting an interrupt calling convention in a stable way.