From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3438 invoked by alias); 22 Oct 2008 07:30:14 -0000 Received: (qmail 3422 invoked by uid 22791); 22 Oct 2008 07:30:12 -0000 X-Spam-Check-By: sourceware.org Received: from wx-out-0506.google.com (HELO wx-out-0506.google.com) (66.249.82.237) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 07:29:12 +0000 Received: by wx-out-0506.google.com with SMTP id t4so1141047wxc.14 for ; Wed, 22 Oct 2008 00:29:09 -0700 (PDT) Received: by 10.70.57.10 with SMTP id f10mr11459052wxa.45.1224660549103; Wed, 22 Oct 2008 00:29:09 -0700 (PDT) Received: from localhost (79-75-25-206.dynamic.dsl.as9105.com [79.75.25.206]) by mx.google.com with ESMTPS id 8sm8853680hsp.4.2008.10.22.00.29.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Oct 2008 00:29:07 -0700 (PDT) From: Richard Sandiford To: Mark Mitchell Mail-Followup-To: Mark Mitchell ,"Weddington\, Eric" , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: "Weddington\, Eric" , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] MIPS function attributes for interrupt handlers In-Reply-To: <48FE5091.4000406@codesourcery.com> (Mark Mitchell's message of "Tue\, 21 Oct 2008 14\:58\:41 -0700") References: <48FCFDAB.604@codesourcery.com> <258DDD1F44B6ED4AAFD4370847CF58D502FB5607@csomb01.corp.atmel.com> <48FE00FF.5040504@codesourcery.com> <87y70h1xm6.fsf@firetop.home> <48FE5091.4000406@codesourcery.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (gnu/linux) Date: Wed, 22 Oct 2008 10:03:00 -0000 Message-ID: <87vdvlhyv6.fsf@firetop.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg00915.txt.bz2 Mark Mitchell 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