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