Support of __bic_SR_register_on_exit and __bis_SR_register_on_exit builtins

[chbessonova]

These two built-ins are supported by TI/IAR/GCC compilers directly, and not declared/defined in in430.h as other similar built-ins.
Since these BIs are not supported by clang, it causes link error, which made not possible to build targets like Contiki.

This is from gcc docs:

__bic_SR_register_on_exit (int mask)
This clears the indicated bits in the saved copy of the status register that currently resides on the stack.
This only works inside interrupt handlers and the changes to the status register only take effect after the handler returns.
__bis_SR_register_on_exit (int mask) 
This sets the indicated bits in the saved copy of the status register that currently resides on the stack.
This only works inside interrupt handlers and the changes to the status register only take effect after the handler returns.

It looks to me that it is not possible to achieve the same functionality by inline asm, but I'll will investigate further.

If someone has some thoughts about this, I'll appreciate for the help.

[chbessonova]

Well, interrupts push SR to the stack according to MSP430 EABI before calling interrupt handler:

Interrupts push the SR and PC registers onto the stack and branch to an interrupt handler. 
To return from an interrupt function, the function must execute the special instruction RETI, 
which restores the SR register and branches to the PC where the interrupt occurred.

__bic_SR_register_on_exit and __bis_SR_register_on_exit should change this saved copy of SR.
I don't see any ways how to get access to it through inline asm. So, I'll try to implement them as intrinsics.

[pftbest]

It is possible to use existing @llvm.frameaddress intrinsic, but it forces the use of a frame pointer which will waste a register. Maybe a dedicated intrinsic can do better than that.

https://godbolt.org/z/W5MCP2

[chbessonova]

@pftbest Hi! Thanks for pointing to this. But shouldn't it be bis access-softek/msp430-clang#1, 2(r4) to change an SR copy pushed before a branch to interrupt handler?

[pftbest]

Yes, you are right, it should be 2(r4) because push r4 instruction decrements sp so bis access-softek/msp430-clang#1,0(r4) will just corrupt the old value of r4.

https://godbolt.org/z/JG7tzv

[dmikushin]

@chbessonova What about an undefined reference to __bis_SR_register? Should it be resolved by compiler as an intrinsic as well?

[chbessonova]

@dmikushin No or at least it is not necessary. You can find all the other built-ins implementation in in430.h, provided by TI with GCC packet.

[chbessonova]

Except for the solution with @llvm.frameaddress I see two more:

• consider saved copy of status register as an argument of interrupt handler (a draft implementation chbessonova/msp430-clang@72d8c79, inspired by x86 interrupt handlers implementation).
  AFAIK, all other MSP430 toolchains do not allow interrupt handlers to have arguments, but MSP430 EABI says nothing about this.
  With an explicit argument, this solution has a quite simple implementation.
• implement dedicated intrinsics (a draft implementation chbessonova/msp430-clang@e8c64d7).

I'll appreciate the feedback.

[dmikushin]

FWIW, here is a "nice" syntax CCS has for MSP430X, FreeRTOS code:

#pragma vector=configTICK_VECTOR
interrupt void vTickISREntry( void )
{
extern void vPortTickISR( void );

        __bic_SR_register_on_exit( SCG1 + SCG0 + OSCOFF + CPUOFF );
        #if configUSE_PREEMPTION == 1
                extern void vPortPreemptiveTickISR( void );
                vPortPreemptiveTickISR();
        #else
                extern void vPortCooperativeTickISR( void );
                vPortCooperativeTickISR();
        #endif
}

[chbessonova]

Friendly ping :)

[asl]

I would prefer the second variant – explicit intrinsics. I don't like the special logic for this "shadow" argument.