Source code reusability

Charles-Antoine Gauthier charles.gauthier at nrc.ca
Mon Oct 23 17:17:31 UTC 2000


Ralf Corsepius wrote:
> 
> Charles-Antoine Gauthier wrote:
> >
> > The GCC team recommends the use of __attribute__ over pragma. Look in
> > the docs under C extensions, function attributes.
> >
> >   Some people object to the `__attribute__' feature, suggesting that
> >   ANSI C's `#pragma' should be used instead.  There are two reasons for
> >   not doing this.
> >
> >     1. It is impossible to generate `#pragma' commands from a macro.
> >
> >     2. There is no telling what the same `#pragma' might mean in another
> >        compiler.
> >
> You're right, however Silverio is probably to the Hitachi SH.
> 
> IIRC, there was a time when __attribute__(interrupt)  for the SH was
> completely hosed in gcc's SH backend or wasn't even supported at the
> time we ported RTEMS to the SH.
> 
> Things might have changed since then, but last time I checked for
> this issue, it was still present (BTW: Even #pragma interrupt is
> broken).
> 
> > The documentation also contains:
> >
> > `interrupt'
> >      Use this option on the M32R/D to indicate that the specified
> >      function is an interrupt handler.  The compiler will generate
> >      function entry and exit sequences suitable for use in an interrupt
> >      handler when this attribute is present.
> >
> > `interrupt_handler'
> >      Use this option on the H8/300 and H8/300H to indicate that the
> >      specified function is an interrupt handler.  The compiler will
> >      generate function entry and exit sequences suitable for use in an
> >      interrupt handler when this attribute is present.
> >
> > Unless you are using either of these CPUs, I would not assume that
> > #pragma interrupt does anything.
> 
> It is also valid for the SH.
> 
> > Silverio Diquigiovanni wrote:
> > >
> > > Hi to all,
> > >
> > > I'm aware that this isn't a good request to submit to this mail list,
> > > but with faith in your experience in matter of reusable source code I
> > > hope you can help me.
> > >
> > > The question:
> > >
> > > - I have three compilers which I normally use every day :
> > >
> > >   Green Hills compiler
> > >   GNU gcc compiler
> > >   IAR compiler
> > >
> > > The source code is largely reusable because I use always ANSI compliant
> > > normative, but today have a problem with interrupt functions.
> > >
> > > I must create a mechanism for declarin a function like interrupt
> > > function whitout use a compiler dipendent syntax.
> > >
> > > Green Hills uses :
> > >   void interrupt my_fun( void ) { }
> > >
> > > GNU uses:
> > >   #pragma interrupt
> > >   void my_fun( void ) { }
> > >
> > > IAR uses:
> > >   void interrupt[vect_num] my_fun( void ) { }
> > >
> > > My initial idea was be usign a macro to implement the different
> > > compiler implementation.
> > >
> > > #ifdef __GREEN_HILLS__
> > >   #define INTERRUPT_FUN(fun,vec)        (.........)
> > > #endif
> > > #ifdef __GNUC__
> > >   #define INTERRUPT_FUN(fun,vec) (#pragma interrupt \ void fun(void))
> > > #endif
> > > #ifdef __IAR__
> > >   #define INTERRUPT_FUN(fun,vec) (void interrupt[vec] fun(void))
> > > #endif
> > >
> > > But #pragma can't be generated by a macro, so the __GNUC__
> > > implementation is impossible....
> 
> Another (semiportable) alternative is to wrap the interrupt stuff
> into inline asm-macros, cf.
> src/lib/libcpu/sh/sh7032/score/ispsh7032.c

Highly recommended approach. Also, if the timing allows, consider using
the RTEMS first level interrupt handler. I would never trust a compiler
to do the right thing (e.g. with some systems, address translation may
need to be turned back on ASAP). At least, check the generated code for
sanity.

> 
> > >
> > > Have you some suggestion about ?
> 
> Ralf
> 
> --
> Ralf Corsepius
> Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
> (FAW)
> Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
> mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999
> http://www.faw.uni-ulm.de

-- 
Charles-Antoine Gauthier
Institute for Information Technology   Institut de technologie de
l'information
National Research Council of Canada    Conseil national de recherches du
Canada



More information about the users mailing list