From owner-cvs-all@FreeBSD.ORG Sat Jun 28 12:08:14 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D68106568A for ; Sat, 28 Jun 2008 12:08:14 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 3039E8FC14 for ; Sat, 28 Jun 2008 12:08:12 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 28 Jun 2008 12:08:11 -0000 Received: from p54A3DE64.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.222.100] by mail.gmx.net (mp019) with SMTP; 28 Jun 2008 14:08:11 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19YKkwXxjFYtjJ4NJEL/0whqorHB7D9tFCmXynCJc rlwILzlcgYNH1n Message-ID: <486629AA.1050409@gmx.de> Date: Sat, 28 Jun 2008 14:08:10 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.9 (X11/20071230) MIME-Version: 1.0 To: Marius Strobl References: <200806252105.m5PL5AUp064418@repoman.freebsd.org> <48654667.1040401@gmx.de> <20080627222404.GJ1215@alchemy.franken.de> <48657058.6020102@gmx.de> <20080628114417.GL1215@alchemy.franken.de> In-Reply-To: <20080628114417.GL1215@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sparc64/include in_cksum.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2008 12:08:14 -0000 Marius Strobl wrote: >> On a related note: Is inline assembler really necessary here? For >> example couldn't in_addword() be written as >> static __inline u_short >> in_addword(u_short const sum, u_short const b) >> { >> u_int const t = sum + b; >> return t + (t >> 16); >> } ? >> This should at least produce equally good code and because the compiler >> has more knowledge about it than an assembler block, it potentially >> leads to better code. I have no SPARC compiler at hand, though. > > With GCC 4.2.1 at -O2 the code generated for the above C version > takes on more instruction than the inline assembler so if one On SPARC? What code does it produce? I have not SPARC compiler at hand. Even if it is one more instruction, I think the reduced register pressure makes more than up for it. > wants to go for micro-optimizing one should certainly prefer the > inline assembler version. As a compiler construction I can tell you, that regarding optimisation there is no such thing as "certainty". The worst part about inline assembler is, that the compiler knows nothing about the instructions in there and has to copy them verbatim. For example it can not do any clever things with the two shifts at the beginning of the inline assembler block of in_addword(). >> In fact the in/out specification for this asm block looks rather bad: >> "=&r" (__ret), "=&r" (__tmp) : "r" (sum), "r" (b) : "cc"); >> The "&"-modifiers (do not use the same registers as for any input >> operand value) force the compiler to use 4 (!) register in total for >> this asm block. It could be done with 2 registers if a proper in/out >> specification was used. At the very least the in/out specification can >> be improved, but I suspect using plain C is the better choice. >> > > The "&"-modifiers are necessary as the inline assembler in > question consumes output operands before all input operands > are consumed. Omitting them caused GCC to generate broken > code in the past. This should work fine and only use two registers (though the compiler can choose to use three, if it deems it beneficial): static __inline u_short in_addword(u_short const sum, u_short const b) { u_long const sum16 = sum << 16; u_long const b16 = b << 16; u_long ret; __asm( "addcc %1, %2, %0\n\t" "srl %0, 16, %0\n\t" "addc %0, 0, %0\n" : "=r" (ret) : "r" (sum16), "r" (b16) : "cc"); return (ret); } But I still prefer the C version. Regards Christoph