From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14864 invoked by alias); 5 Oct 2011 07:26:54 -0000 Received: (qmail 14854 invoked by uid 22791); 5 Oct 2011 07:26:52 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,TW_GD X-Spam-Check-By: sourceware.org Received: from asav4.lyse.net (HELO asav4.lyse.net) (81.167.36.150) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 07:26:35 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by asav4.lyse.net (Postfix) with ESMTP id 67B936C0E9; Wed, 5 Oct 2011 09:26:33 +0200 (CEST) Received: from localhost.localdomain (unknown [79.161.10.130]) by asav4.lyse.net (Postfix) with ESMTP id 790176C10B; Wed, 5 Oct 2011 09:26:32 +0200 (CEST) Received: from [192.168.0.60] (helo=[192.168.0.60]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1RBLs8-0006uV-6M; Wed, 05 Oct 2011 09:26:32 +0200 Message-ID: <4E8C05C7.6010502@westcontrol.com> Date: Wed, 05 Oct 2011 09:31:00 -0000 From: David Brown User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 Newsgroups: gmane.comp.gcc.devel To: Andrew Pinski CC: David Brown , Iain Buclaw , Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: Merging gdc (GNU D Compiler) into gcc References: <4E8B7D63.3070206@hesbynett.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00068.txt.bz2 On 04/10/2011 23:47, Andrew Pinski wrote: > On Tue, Oct 4, 2011 at 2:40 PM, David Brown wrote: >> "naked" functions are often useful in embedded systems, and are therefore >> useful (and implemented) on many gcc targets. It would make sense to have >> the attribute available universally in gcc, if that doesn't involve a lot of >> extra work, even though it is of little use on "big" systems (Linux, >> Windows, etc.). > > Is it really useful if you can have a small top-level inline-asm wrapper? > The "naked" attribute is used precisely when you don't want any wrapper or other code that you don't absolutely need. An example of use is when you want to write the prologue and epilogue manually - perhaps the compiler's standard interrupt function prologue and epilogue are not quite good enough for a special case, so you write your own inline assembly. You don't want the compiler to generate additional register saves, frame manipulation, etc. Some toolchains are configured to have a series of "init" sections at startup (technically, that's a matter of the default linker scripts and libraries rather than the compiler). You can get code to run at specific times during startup by placing the instructions directly within these sections - but it must be "raw" instructions, not function definitions (and definitely no "return" statement). The stack may not be defined at this stage - perhaps you are using such code to initialise the memory system or do other low-level setup. For an example, see this link: I've also used "naked" functions to provide a place to store specific assembly code - I prefer to use inline assembly in C rather than a separate assembly module. RTOS'es often use "naked" in connection with tasks and task switching. After the RTOS has gone to all the effort of saving the registers and task context, it needs to jump into the next task without there being more overhead of stored registers. On small RISC microcontrollers, it's possible for the register bank to be a significant proportion of the size of the chip's ram - you don't want to waste the space or the time saving things unnecessarily. Using the "naked" attribute means a little more of such code can be written in C, and a little less needs to be written in assembly. That's a good thing. And making "naked" consistent across more gcc ports means a little more of such code can be cross-target portable, which is also a good thing. You are never going to eliminate all target-specific parts of such code, nor can you eliminate all assembly - but "naked" is a step in that direction. While I'm on the subject, it would be /very/ nice if the gcc port maintainers agreed on function (and data) attributes. Clearly there will be some variation between target ports, but surely it would be easier to write, port and maintain if there were more consistency. From a user's viewpoint, it is hard to understand why some targets use "long_call" attributes and others use "longcall" to do the same thing, or why there are a dozen different ways to declare an interrupt function on different architectures. If these can be combined, it would be less effort for the port maintainers, easier for users, and less documentation. It might also make it easier for useful attributes (like "naked", or "critical") to spread to other target ports. mvh., David From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16224 invoked by alias); 5 Oct 2011 07:27:04 -0000 Received: (qmail 16111 invoked by uid 22791); 5 Oct 2011 07:27:03 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GD X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 07:26:47 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RBLsL-0007dB-6Q for gcc@gcc.gnu.org; Wed, 05 Oct 2011 09:26:45 +0200 Received: from 79.161.10.130 ([79.161.10.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Oct 2011 09:26:45 +0200 Received: from david by 79.161.10.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Oct 2011 09:26:45 +0200 To: gcc@gcc.gnu.org From: David Brown Subject: Re: Merging gdc (GNU D Compiler) into gcc Date: Wed, 05 Oct 2011 10:00:00 -0000 Message-ID: <4E8C05C7.6010502@westcontrol.com> References: <4E8B7D63.3070206@hesbynett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: David Brown , Iain Buclaw , Ian Lance Taylor , gcc@gcc.gnu.org User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00069.txt.bz2 Message-ID: <20111005100000.RH0b1fyl7Rz3U2neCCjHXrxVreYQLpOV3Z-xNxbt3iw@z> On 04/10/2011 23:47, Andrew Pinski wrote: > On Tue, Oct 4, 2011 at 2:40 PM, David Brown wrote: >> "naked" functions are often useful in embedded systems, and are therefore >> useful (and implemented) on many gcc targets. It would make sense to have >> the attribute available universally in gcc, if that doesn't involve a lot of >> extra work, even though it is of little use on "big" systems (Linux, >> Windows, etc.). > > Is it really useful if you can have a small top-level inline-asm wrapper? > The "naked" attribute is used precisely when you don't want any wrapper or other code that you don't absolutely need. An example of use is when you want to write the prologue and epilogue manually - perhaps the compiler's standard interrupt function prologue and epilogue are not quite good enough for a special case, so you write your own inline assembly. You don't want the compiler to generate additional register saves, frame manipulation, etc. Some toolchains are configured to have a series of "init" sections at startup (technically, that's a matter of the default linker scripts and libraries rather than the compiler). You can get code to run at specific times during startup by placing the instructions directly within these sections - but it must be "raw" instructions, not function definitions (and definitely no "return" statement). The stack may not be defined at this stage - perhaps you are using such code to initialise the memory system or do other low-level setup. For an example, see this link: I've also used "naked" functions to provide a place to store specific assembly code - I prefer to use inline assembly in C rather than a separate assembly module. RTOS'es often use "naked" in connection with tasks and task switching. After the RTOS has gone to all the effort of saving the registers and task context, it needs to jump into the next task without there being more overhead of stored registers. On small RISC microcontrollers, it's possible for the register bank to be a significant proportion of the size of the chip's ram - you don't want to waste the space or the time saving things unnecessarily. Using the "naked" attribute means a little more of such code can be written in C, and a little less needs to be written in assembly. That's a good thing. And making "naked" consistent across more gcc ports means a little more of such code can be cross-target portable, which is also a good thing. You are never going to eliminate all target-specific parts of such code, nor can you eliminate all assembly - but "naked" is a step in that direction. While I'm on the subject, it would be /very/ nice if the gcc port maintainers agreed on function (and data) attributes. Clearly there will be some variation between target ports, but surely it would be easier to write, port and maintain if there were more consistency. From a user's viewpoint, it is hard to understand why some targets use "long_call" attributes and others use "longcall" to do the same thing, or why there are a dozen different ways to declare an interrupt function on different architectures. If these can be combined, it would be less effort for the port maintainers, easier for users, and less documentation. It might also make it easier for useful attributes (like "naked", or "critical") to spread to other target ports. mvh., David