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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox