From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KFwLW-0000BZ-Dz for mharc-grub-devel@gnu.org; Mon, 07 Jul 2008 15:25:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KFwLV-0000BJ-FJ for grub-devel@gnu.org; Mon, 07 Jul 2008 15:25:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KFwLT-0000B0-UC for grub-devel@gnu.org; Mon, 07 Jul 2008 15:25:57 -0400 Received: from [199.232.76.173] (port=35826 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KFwLT-0000Ax-Ow for grub-devel@gnu.org; Mon, 07 Jul 2008 15:25:55 -0400 Received: from mailout01.t-online.de ([194.25.134.80]:38175) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KFwLS-0003PM-7t for grub-devel@gnu.org; Mon, 07 Jul 2008 15:25:55 -0400 Received: from fwd34.aul.t-online.de by mailout01.t-online.de with smtp id 1KFwLK-0006uy-04; Mon, 07 Jul 2008 21:25:46 +0200 Received: from [10.3.2.2] (JlpTk4ZLwhhF5fZiL+eX3DGIvBGY6346YpgO8m55othab9+gqpMqCDr4ekNFe7ZgS-@[217.235.244.50]) by fwd34.aul.t-online.de with esmtp id 1KFwLE-1r3akq0; Mon, 7 Jul 2008 21:25:40 +0200 Message-ID: <48726DB3.9000809@t-online.de> Date: Mon, 07 Jul 2008 21:25:39 +0200 From: Christian Franke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: The development of GRUB 2 References: <1215264476.26019.160.camel@localhost> <1215293427.17114.2.camel@dv> <1215298499.26019.192.camel@localhost> <20080706183042.GA22023@thorin> <1215374534.26019.194.camel@localhost> In-Reply-To: <1215374534.26019.194.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ID: JlpTk4ZLwhhF5fZiL+eX3DGIvBGY6346YpgO8m55othab9+gqpMqCDr4ekNFe7ZgS- X-TOI-MSGID: d22ea580-c20c-42d3-83e8-ccdadf0fe041 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: Endianness macros capitalization X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 19:25:57 -0000 Javier Martín wrote: > El dom, 06-07-2008 a las 20:30 +0200, Robert Millan escribió: > >> On Sun, Jul 06, 2008 at 12:54:58AM +0200, Javier Martín wrote: >> >>> El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió: >>> >>>> They probably should be functions. We may want to sparse annotate GRUB >>>> one day, and then inline functions in the only way to go. >>>> >>> Hmm... you mean changing this >>> >>> #define grub_swap_bytes16(x) \ >>> ({ \ >>> grub_uint16_t _x = (x); \ >>> (grub_uint16_t) ((_x << 8) | (_x >> 8)); \ >>> }) >>> >>> ...for this >>> >>> inline grub_uint16_t grub_swap_bytes16(uint16_t x) >>> { >>> return (x << 8) | (x >> 8); >>> } >>> >> I know I get to be annoying about this, but which of these two (plus the >> non-inline version) would result in _smaller_ code? >> >> Function calls on i386-pc are cheap (because we use the regparm hack), so >> maybe it'd work better using normal functions. >> >> Assembly code for grub_swap_bytes16 from Debian gcc 4.1.2-7: Macro or Inline: 4 bytes (minus possible additional benefit from register level optimizations) 66 c1 c0 08 rol $0x8,%ax Function call: 11 bytes 0f b7 c0 movzwl %ax,%eax e8 xx xx xx xx call grub_swap_bytes16 0f b7 c0 movzwl %ax,%eax The break even is possibly at grub_swap_bytes64() :-) > If we are to take the space-saving route, the best we can do is turn > them to functions, maybe even _without_ the "inline" keyword, and GCC > will do what's best. > > How can this be accomplished for functions in include files? If non-inline functions are declared non-static in an include file, duplicate symbols will result (Even with 'inline' you have to be careful due to different inline modes). If declared static and GCC decides to emit a function instead of inline, the code will be duplicated in all modules which use this function. AFAIK, GCC supports 'vague linkage' code (each put in an extra section with '.linkonce' attribute) only for C++, but not for C. Or is there a GCC specific function attribute to accomplish this? Christian