Re: [PATCH] MIPS function attributes for interrupt handlers

[Richard Sandiford <rdsandiford@googlemail.com>]

Mark Mitchell <mark@codesourcery.com> writes:
> 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.

I'm not convinced by this example.  GCC already provides a much
more powerful way of doing this: extended asms.  Such an extended
asm has many benefits over naked functions:

  - It can be inlined into bigger functions.  That way, locks don't
    need to be function calls.

  - Other GCC features like function profiling continue to work correctly.

  - There is no need for an attribute.  GCC can tell what resources the
    asm needs, so when optimisation is enabled, GCC won't generate a
    prologue unless the asm needs one.

  - GCC can emit asm directives that depend on the code itself.
    Take the MIPS .frame pseudo-op as an example.  GCC doesn't
    know how much stack space a naked asm uses (if any), or what
    GPRs it uses, so it can't output a correct .frame for it.
    It _can_ (and does) output correct .frames for functions
    containing extended asms.

  - The extended-asm approach is _genuinely_ consistent across platforms.
    All ports support extended asms, and have done for many GCC releases.

    On the other hand, if we did decide to extend the naked attribute to
    other ports, it's likely to be several releases at least before it
    is genuinely consistent.  People would need to know which version of
    GCC first supported the attribute on the targets they care about.

AIUI, the only "advantage" of naked asms over extended asms is that they
allow you to do things that you wouldn't normally be allowed to do, like
write directly to the result register.  But why not simply bind the
return value to an output operand in an extended asm?  Is that
really much uglier than writing "__attribute__((naked))"?

Also, because naked functions cannot refer to their arguments, you will
get a warning for C unless you write:

  void __attribute__((naked))
  foo (int arg1 __attribute__((unused)), 
       int arg2 __attribute__((unused)))
  {
    ...;
  }

The macro definitions themselves would presumably look like:

  #define LOAD_AND_ADD_1 asm ("\
     lw $2,($4)\
     addiu $2,$2,1\
  ")

The combination of these two doesn't seem any prettier or easier
to me than having a source code file:

  FUNC_START(foo)
    lw $2,($4)
    addiu $2,$2,1
  FUNC_END(foo)

(which among other things avoids those infernal backslashes).

I agree with what Thiemo said about defining these assembly macros.
You said in reply that they were hard to write, but the point is that,
for the ports we're talking about, you don't need to.  Other people
already have.  (And most of the architectural differences between
these macros are historical.  GAS itself is much more consistent.)

It just seems to me that we're trying to introduce a feature in the name
of cross-platform consistency in cases where (a) in the foreseeable
future, "cross-platform" will mean "across a handful of targets" and
(b) we already have a better feature that is genuinely cross-platform.
(I say "foreseeable future" because we can't of course predict what
people will contribute.)

Richard