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>
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.