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] MIPS function attributes for interrupt handlers


Mark Mitchell wrote:
> Richard Sandiford wrote:
> 
> > I still disagree, for the reasons given before.  MIPS assembly coders
> > already have preprocessor macros to prettify the assembly function
> > declaration syntax.  If the only point of the attribute is to write
> > out that syntax, I don't think the attribute is a win.
> 
> I disagree on that point.  Assembly function declaration syntax is
> complex, and varies from OS to OS, and depends on things like whether
> the function is hidden, static, etc.  Making this an
> architecture-independent attribute seems beneficial, as one of GCC's
> core advantages is cross-platform consistency.
> 
> For example, writing:
> 
>   void mylock()
>     __attribute__((hidden))
>     __attribute__((naked)) {
>     ARCH_MYLOCK;
>   }
> 
> where ARCH_MYLOCK is a macro that expands to the CPU-specific assembly
> implementation of a locking primitive seems likely to be useful.  Much
> better than lots of #ifdef __linux__ and #ifdef __mips__ goo in a pure
> assembler file.

The ifdef goo goes typically in the implementation of ARCH_MYLOCK,
declaring function entry/attributes etc. is easy to hide in preprocessor
macros.

AFAICS the best practical reason for __attribute__((naked)) is that it
allows to stick a mix of C and assembler which logically belongs together
in the same file. Currently the implementation of such code must be split
in a non-intuitive manner.


Thiemo


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