MSP430 in gcc4.9 ... enable interrupts?

MSP430 in gcc4.9 ... enable interrupts?

[Brian Drummond]

I have built a crosscompiler for the MSP430, using a gcc4.9 snapshot
(gcc-4.9-20140112) and the compiler seems OK and builds a simple
"blinky" LED flashing example.

But my slightly larger example, originally built using Peter Bigot's
mspgcc backend, no longer compiles ... 

mspgcc had a number of intrinsic functions, such as __nop(), __eint()
and __dint() respectively. Calling these would execute a nop, enable and
disable interrupts respectively. 

Others such as __bis_status_register(), __bic_status_register() would
manipulate system status, low power modes etc.

Now in the MSP430 port for gcc4.9, these intrinsic functions have gone. 

Perusing the config/msp430 source files, e.g. config/msp430/msp430.md I
can see evidence that the _functionality_ is still there, e.g.

(define_insn "enable_interrupts"
  [(unspec_volatile [(const_int 0)] UNS_EINT)]
  ""
  "EINT"
  )
...
(define_insn "bis_SR"
  [(unspec_volatile [(match_operand 0 "nonmemory_operand" "ir")]
UNS_BIS_SR)]
  ""
  "BIS.W\t%0, %O0(SP)"
  )

... but how do I access it? In other words, what C code fragment would
cause the "enable_interrupts" instruction to be emitted, and generate
"EINT" in the assembler or object output?

- Brian

Re: MSP430 in gcc4.9 ... enable interrupts?

[DJ Delorie]

The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those).  You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline assembler in a common
header file:

static inline __attribute__((always_inline))
void __nop()
{
  asm volatile ("NOP");
}

static inline __attribute__((always_inline))
void __eint()
{
  asm volatile ("EINT");
}


Or more simply:

#define __eint() asm("EINT")
#define __nop() asm("NOP")


For opcodes with parameters, you use a more complex form of inline
assembler:

static inline __attribute__((always_inline))
void BIC_SR(const int x)
{
  asm volatile ("BIC.W %0,R2" :: "i" (x));
}

Re: MSP430 in gcc4.9 ... enable interrupts?

[Brian Drummond]

On Fri, 2014-02-14 at 14:17 -0500, DJ Delorie wrote:
> The constructs in the *.md files are for the compiler's internal use
> (i.e. there are function attributes that trigger those).  You don't
> need compiler support for these opcodes at the user level; the right
> way is to implement those builtins as inline assembler 

> static inline __attribute__((always_inline))
> void __nop()
> {
>   asm volatile ("NOP");
> }

Thanks for the answer. I thought I was missing something, but apparently
not. Now it's clear that inline assembler is the official way, I can
adapt that approach to my situation. 

- Brian

Re: MSP430 in gcc4.9 ... enable interrupts?

[David Brown]

On 14/02/14 20:17, DJ Delorie wrote:
> The constructs in the *.md files are for the compiler's internal use
> (i.e. there are function attributes that trigger those).  You don't
> need compiler support for these opcodes at the user level; the right
> way is to implement those builtins as inline assembler in a common
> header file:
>
> static inline __attribute__((always_inline))
> void __nop()
> {
>    asm volatile ("NOP");
> }
>
> static inline __attribute__((always_inline))
> void __eint()
> {
>    asm volatile ("EINT");
> }
>
>
> Or more simply:
>
> #define __eint() asm("EINT")
> #define __nop() asm("NOP")
>
>
> For opcodes with parameters, you use a more complex form of inline
> assembler:
>
> static inline __attribute__((always_inline))
> void BIC_SR(const int x)
> {
>    asm volatile ("BIC.W %0,R2" :: "i" (x));
> }
>

I presume these will be part of the headers for the library distributed 
for msp430 gcc by TI/Redhat?  (I know that's a bit off-topic for the gcc 
list, but it is relevant to msp430 gcc users who don't want to have to 
learn inline assembly.)  I certainly think that's the right way to 
handle this sort of thing - if it can be just as efficiently put in 
headers using inline assembly, then maintenance is easier than putting 
it into gcc itself.

When you say that the interrupt control in the compiler is for function 
attributes, is that for the "critical" attribute that exists in the old 
msp430 port (which disables interrupts for the duration of the 
function)?  I don't see it mentioned in the current gcc documentation, 
but I haven't tried the code itself.  It was certainly a nice idea - and 
one that I would love to see supported on a range of gcc ports rather 
than just the msp430.

David

Re: MSP430 in gcc4.9 ... enable interrupts?

[DJ Delorie]

> I presume these will be part of the headers for the library
> distributed for msp430 gcc by TI/Redhat?

I can't speak for TI's or Red Hat's plans.  GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way of chip-specific headers or library functions.

> is that for the "critical" attribute that exists in the old msp430
> port (which disables interrupts for the duration of the function)?

Yes, for things like that.  They're documented under "Function
Attributes" in the "Extensions to the C Language Family" chapter of
the current GCC manual.

Re: MSP430 in gcc4.9 ... enable interrupts?

[David Brown]

On 18/02/14 00:12, DJ Delorie wrote:
>> I presume these will be part of the headers for the library
>> distributed for msp430 gcc by TI/Redhat?
> 
> I can't speak for TI's or Red Hat's plans.  GNU's typical non-custom
> embedded runtime is newlib/libgloss, which usually doesn't have that
> much in the way of chip-specific headers or library functions.

Fair enough.  I don't know if Red Hat will be distributing anything
themselves, but I'm confident that TI will distribute chip-specific
headers with pre-built msp430 gcc packages (their aim, after all, is to
get more people to buy msp430 chips - and making the tools as easy and
powerful as possible is part of that).  I was just wondering where these
headers would fit in.

> 
>> is that for the "critical" attribute that exists in the old msp430
>> port (which disables interrupts for the duration of the function)?
> 
> Yes, for things like that.  They're documented under "Function
> Attributes" in the "Extensions to the C Language Family" chapter of
> the current GCC manual.
> 

Ah yes, I missed it when I first looked - the documentation makes
"critical" look like an option to the "interrupt" attribute, rather than
a stand-alone attribute.  It seems to me a rather strange idea to have
both "interrupt" and "critical" on the same function - an "interrupt"
function is inherently "critical" (and "reentrant") in that interrupts
are disabled before it enters, and restored or re-enabled on exit.  It
would make a difference on processors like ARMs with several interrupt
levels, but not on an msp430 with its single level.

David