public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: i386 flags register clober in inline assembly
Date: 17 Nov 2001 11:58:25 -0800	[thread overview]
Message-ID: <9t6fh1$len$1@cesium.transmeta.com> (raw)
In-Reply-To: <87y9l58pb5.fsf@fadata.bg> <200111171920.fAHJKjJ01550@penguin.transmeta.com>

Followup to:  <200111171920.fAHJKjJ01550@penguin.transmeta.com>
By author:    Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
>
> In article <20011117161436.B23331@atrey.karlin.mff.cuni.cz> you write:
> >
> >They don't need to be. On i386, the flags are (partly for historical reasons) clobbered
> >by default.
> 
> However, this is one area where I would just be tickled pink if gcc were
> to allow asm's to return status in eflags, even if that means that we
> need to fix all our existing asms.
> 
> We have some really _horrid_ code where we use operations that
> intrinsically set the flag bits, and we actually want to use them.
> Using things like cmpxchg, and atomic decrement-and-test-with-zero have
> these horrid asm statements that have to move the eflags value (usually
> just one bit) into a register, so that we can tell gcc where it is.
> 

The clean way to do that would be for gcc to implement _Bool, the C99
boolean data type, and add a new kind of register for the flags, i.e.

_Bool c;

asm volatile(LOCK "subl %2,%0"
    : "=m" (v->counter), "=zf" (c)
    : "ir" (i), "0" (v->counter) : "memory", "cc");

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

  reply	other threads:[~2001-11-17 19:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-17 14:06 i386 flags register clober in inline assembly Momchil Velikov
2001-11-17 15:14 ` Jan Hubicka
2001-11-17 19:20 ` Linus Torvalds
2001-11-17 19:58   ` H. Peter Anvin [this message]
2001-11-17 20:24   ` Momchil Velikov
2001-11-17 20:30     ` Linus Torvalds
2001-11-17 20:40   ` Jan Hubicka
2001-11-17 20:42     ` Linus Torvalds
2001-11-18  1:09       ` Jan Hubicka
2001-11-18  2:48         ` Linus Torvalds
2001-11-20  8:33           ` Richard Henderson
2001-11-20 13:00             ` Jan Hubicka
2001-11-20 23:14               ` Richard Henderson
2001-11-20 17:12             ` Linus Torvalds
2001-11-17 21:00     ` H. Peter Anvin
2001-11-20 14:39   ` PATCH 2.4.15-pre6 idt compilation and proc_misc cleanup Martin Dalecki
2001-11-23 22:24     ` Roman Zippel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='9t6fh1$len$1@cesium.transmeta.com' \
    --to=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox