On 14/02/14 00:12, Brian Drummond wrote:
> 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 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
>
If you want help about the guts of the compiler, you are probably better
posting to the gcc development mailing list at <gcc@xxxxxxxxxxx>. I
know that the guys doing the msp430 gcc port follow that list. Another
useful place is the mspgcc users' list <mspgcc-users@xxxxxxxxxxxxxxxxxxxxx>.
But if you just want a fix that you can use, then use inline assembly:
#define __eint() asm volatile(" eint" ::: "memory")
and so on.
Personally, I think there is no point in including intrinsic functions
in the compiler if the same thing can be achieved with inline assembly
like this in the library headers (at least for ports such as the msp430
where the developers have much more control of the headers), because
definitions in headers makes maintenance easier.
