Re: [PATCH 2/5] atomic: introduce atomic_inc_not_zero

[David S. Miller]

From: Roman Zippel <zippel@xxxxxxxxxxxxxx>
Date: Sat, 17 Sep 2005 02:59:50 +0200 (CEST)

> My biggest problem here is the lack of gcc support to get the
> condition code out of an asm.

I agree, this is the biggest deficiency in gcc inline assembly and I
run into it all the time.

Things like __builtin_trap() would never even be needed if we could
communicate condition code state into and out of inline asm
statements, for example.

Sparc32 and sparc64 both have "trap on condition code" instructions.
__builtin_trap() will do the right thing, _BUT_ I want to emit nice
bug table entries like ppc64 does in asm-ppc64/bug.h, but I can't do
that without generating really crappy code.  And the whole limitation
comes from the fact that I can't tell ask gcc for "the condition codes
that result from test X" as the input for an asm.

So what would be great is something akin to:

	__asm__ __volatile__("t%cc	0x5"
			     : "=C" (test));

or something like that.  The "%cc" thing would be expand to the
appropriate two/three letter condition test type code, for example
"ne", "eq", "ge", "ltu" and the like.  GCC could choose the best
comparison + %cc code, as it already does for conditional branch
generation.

It could even help on platforms like ppc64 where the trap condition
instruction does a test of a register against an immediate value.
Something like "BUG_ON(a != 2)" is probably emitting something like:

	sub	%a, 2, %tmp
	tdnei	%tmp, 0

whereas this could be:

	tdnei	%tmp, 2

if GCC has some inline asm condition code input facility like the
above.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/