This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] m68k: Accept "interrupt" attribute.


Bernardo Innocenti wrote:
> Bernardo Innocenti wrote:
> 
>> While I agree on the general principle, in the case of
>> __attribute__((interrupt)), it should be noted that using the
>> same name across all backends is not going to improve consistency
>> that much, because the existing implementations vary greatly in
>> semantics and even syntax.
> 
> On the other end, since some backends are already overloading the
> same two attributes with 10 different meanings.  So we could as
> well merge them into one.
> 
> (yes, I changed my mind within 2 minutes, so what? ;-)

:-)

We (CodeSourcery) distribute GCC for lots of embedded processors for use
in bare-metal programming environments.  This particular issue has come
up several times from our customer base.  The comments tend to be "I've
used GCC before on CPU X, and I wrote __attribute__((interrupt)), now
I'm on ColdFire/fido/68k and it doesn't work."

The GCC documentation for the attribute says:

`interrupt'
     Use this attribute on the ARM, AVR, C4x, M32R/D and Xstormy16
     ports 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.

     Note, interrupt handlers for the m68k, H8/300, H8/300H, H8S, and
     SH processors can be specified via the `interrupt_handler'
     attribute.

There's no suggestion that the semantics are terribly different between
the processors.  The documentation for interrupt_handler is identical.

It's certainly true that interrupts vary (in terms of things like what
happens if you get an interrupt while processing an interrupt, etc.)
across all these CPUs, but from the documentation seems correct: in all
of these cases, the compiler generates appropriate prologue and epilogue
code.  Having a consistent name is useful for users and plays to one of
GCC's greatest technical strengths: support for multiple platforms in a
uniform way.

So, I'd suggest that we accept "interrupt" everywhere.  (It would even
be OK with me to accept it on processors that don't need any special
handling for interrupt routines, just as a no-op, but that seems less
important.)  If the 68K AmigaOS port is contributed, it can always make
the attribute mean something else, if that's important for backwards
compatibility.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]