Date: Sat, 28 Jun 2008 14:08:10 +0200 From: Christoph Mallon <christoph.mallon@gmx.de> To: Marius Strobl <marius@alchemy.franken.de> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sparc64/include in_cksum.h Message-ID: <486629AA.1050409@gmx.de> In-Reply-To: <20080628114417.GL1215@alchemy.franken.de> References: <200806252105.m5PL5AUp064418@repoman.freebsd.org> <48654667.1040401@gmx.de> <20080627222404.GJ1215@alchemy.franken.de> <48657058.6020102@gmx.de> <20080628114417.GL1215@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?486629AA.1050409>