EmbeddedRelated.com
Forums

pragma in a macro?

Started by Chuck Cox October 24, 2005
I'm writing some compiler-independent msp430 code and would like to 
encapsulate all compiler-dependent code inside macros.  This works fine 
until I try to do this for ICC430:

#define INTERRUPT_HANDLER(vector, name)		\
#pragma interrupt_handler name:vector 		\
void name(void)

This generates a "# not followed by macro parameter" compiler error. 
Is 
there some clever way to get the preprocessor to not interpret the # in 
the normal way, yet correctly handle the pragma?

-- 
Chuck Cox - SynchroSystems
chuck@chuc..., cccox@ccco..., www.synchro.com

Beginning Microcontrollers with the MSP430

None that I know of :-(

At 03:59 PM 10/24/2005, Chuck Cox wrote:

>I'm writing some compiler-independent msp430
code and would like to
>encapsulate all compiler-dependent code inside macros.  This works fine
>until I try to do this for ICC430:
>
>#define INTERRUPT_HANDLER(vector, name)         \
>#pragma interrupt_handler name:vector           \
>void name(void)
>
>This generates a "# not followed by macro parameter" compiler
error.  Is
>there some clever way to get the preprocessor to not interpret the # in
>the normal way, yet correctly handle the pragma?
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 


Chuck Cox wrote:
> I'm writing some compiler-independent msp430
code and would like to 
> encapsulate all compiler-dependent code inside macros.  This works fine 
> until I try to do this for ICC430:
> 
> #define INTERRUPT_HANDLER(vector, name)		\
> #pragma interrupt_handler name:vector 		\
> void name(void)
> 
> This generates a "# not followed by macro parameter" compiler
error.  Is 
> there some clever way to get the preprocessor to not interpret the # in 
> the normal way, yet correctly handle the pragma?

The short answer is that you can't...


On the other hand, the latest version of the C standard added something 
called _Pragma, which is an operator that accepts a string that is 
interpreted as the pragma. Some, maybe all, compilers on the MSP430 
market supports this operator.

However, this macro is somewhat tricky to use since it requires a 
string, so unless it's a straight-forward pragma you will need to do a 
lot of preprocessor magic to go from non-string arguments to a full 
string. For example, you can use the following to generate a pragma 
vector, as used by our compilers:

#define STRANGE_VECTOR 100    // Just for the example


// Concatenate two identifiers
#define CONCAT0(x,y) x##y
#define CONCAT(x,y) CONCAT0(x,y)

// PRAGMA, unlike _Pragma it don't want its arguments quoted.
#define PRAGMA(x) _Pragma(#x)

// PV - pragma vector.
#define PV0(x) PRAGMA(vector=x)
#define PV(x) PV0(CONCAT(x,_VECTOR))


PV(STRANGE)
__interrupt void foo(void)
{
}


On the other hand, I'm a bit curious about your example since it uses a 
pragma "interrupt_handler" that isn't accepted by any of the
MSP430 
compiler that I know of.

By the way, John Heenan is maintaining a file for compiler 
interoperability called InterMSP430CompilerPortability.h, you can find 
it in the file section for this mailinglist at yahoo.

     -- Anders Lindgren, IAR Systems
-- 
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Hi Anders,
*raise hand*

At 01:01 AM 10/25/2005, Anders Lindgren wrote:
>...
>On the other hand, I'm a bit curious about your example since it uses a
>pragma "interrupt_handler" that isn't accepted by any of the
MSP430
>compiler that I know of.
>

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 


Thanks Anders for the information below

I have modified InterMSP430CompilerPortability.h in the file section 
of Yahoo when compiling for IAR:

#define PRECONCATARGS(arg1,arg2) arg1##arg2
#define QUOTEPRAGMA(arg) _Pragma(#arg)
#define ISRM_(INTNAME,intfn) QUOTEPRAGMA(vector=PRECONCATARGS
(INTNAME,_VECTOR)) \
__interrupt void intfn (void)

This means it is now possible to use the ISRM_ macro directly in code 
instead. From the file:

//There are two ways to use the portable ISR Macros.
//Either use the ISRM_ macro with the interrupt
//name and function name, say  ISRM_(TIMERA0,Timer_A0)
//or use a predefined version such as ISRM_TIMERA0
//predefined as say
//#define ISRM_TIMERA0 ISRM_(TIMERA0,Timer_A0)
//It is easy to add in your own predefined versions
//to "InterMSP430CompilerPortability.h".

John Heenan

--- In msp430@msp4..., Anders Lindgren <Anders.lindgren@i...> 
wrote:
>
> On the other hand, the latest version of the C standard added 
something 
> called _Pragma, which is an operator that accepts
a string that is 
> interpreted as the pragma. Some, maybe all, compilers on the MSP430 
> market supports this operator.
> 
> However, this macro is somewhat tricky to use since it requires a 
> string, so unless it's a straight-forward pragma you will need to 
do a 
> lot of preprocessor magic to go from non-string
arguments to a full 
> string. For example, you can use the following to generate a pragma 
> vector, as used by our compilers:
> 
> #define STRANGE_VECTOR 100    // Just for the example
> 
> 
> // Concatenate two identifiers
> #define CONCAT0(x,y) x##y
> #define CONCAT(x,y) CONCAT0(x,y)
> 
> // PRAGMA, unlike _Pragma it don't want its arguments quoted.
> #define PRAGMA(x) _Pragma(#x)
> 
> // PV - pragma vector.
> #define PV0(x) PRAGMA(vector=x)
> #define PV(x) PV0(CONCAT(x,_VECTOR))
> 
> 
> PV(STRANGE)
> __interrupt void foo(void)
> {
> }
> 
> 
> On the other hand, I'm a bit curious about your example since it 
uses a 
> pragma "interrupt_handler" that
isn't accepted by any of the MSP430 
> compiler that I know of.
> 
> By the way, John Heenan is maintaining a file for compiler 
> interoperability called InterMSP430CompilerPortability.h, you can 
find 
> it in the file section for this mailinglist at
yahoo.
> 
>      -- Anders Lindgren, IAR Systems
> -- 
> Disclaimer: Opinions expressed in this posting are strictly my own 
and
> not necessarily those of my employer.
>