Re: MSP430 in gcc4.9 ... enable interrupts?
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
Re: MSP430 in gcc4.9 ... enable interrupts?
> 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?
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?
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?
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));
}
MSP430 in gcc4.9 ... enable interrupts?
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
