[lkml]   [2005]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/5] atomic: introduce atomic_inc_not_zero
From: Roman Zippel <>
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

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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-17 09:27    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean