public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: torvalds@transmeta.com (Linus Torvalds)
To: linux-kernel@vger.kernel.org
Subject: Re: i386 flags register clober in inline assembly
Date: Tue, 20 Nov 2001 17:12:16 +0000 (UTC)	[thread overview]
Message-ID: <9te2tg$20d$1@penguin.transmeta.com> (raw)
In-Reply-To: <20011118020957.A10674@atrey.karlin.mff.cuni.cz> <Pine.LNX.4.33.0111171844001.899-100000@penguin.transmeta.com> <20011120003338.A24717@twiddle.net>

In article <20011120003338.A24717@twiddle.net>,
Richard Henderson  <rth@twiddle.net> wrote:
>
>Hmm.  It appears to be easy to do with machine-dependent builtins.  E.g.
>
>	int x;
>	__asm__ __volatile__(LOCK "subl %1,%0"
>			     : "=m"(v->counter) : "ir"(i) : "memory");
>	x = __builtin_ia32_sete();
>	if (x) {

This would obviously be more than useful.

However, at the same time I worry that the syntax of having things
as separate expressions would be a total nightmare to support in the
long run for gcc - making sure that they never split up by mistake
during parsing/tree-forming/CSE/whatever. That makes for a nasty special
case that just sounds like a maintainance headache.

It _sounds_ like you prototyped something like the above to test it
out? If so, how hard would it be to just change the syntax slightly, and
move the "builting_ia32_sete()" syntactically into the __asm__, even if
it as an implementation then gets split out again for now.

That would make it less of a special case - or at least it would be an
_internal_ special case rather than one exported to the user. 

The simplest syntactic extension would obviously be to add a fourth set
of flags, and make the above look somehting like

	char flag;
	__asm__ __volatile__(LOCK "subl %1,%0"
		:"=m" (v->counter)	/* Inputs */
		:"ir" (i)		/* Outputs */
		:"memory"		/* Clobbers */
		:"=Z" (x)		/* Flags (Z/E=equal, A=above, C=carry etc etc*/
		);
	if (x) {
		...

which looks like a reasonable syntax to me. It has the advantage that it
should be _very_ easy and natural to use this syntax on predicate-based
machines like ia64, where the "flags" are trivially predicates. On such
machines I bet that the need to export the predicates is even bigger
than the need to export eflags on x86.

In fact, for predicate architectures it might be reasonable to have both
input and output predicates, which is why I did the "=Z" syntax (so that
if you find it useful to do _input_ predicates, you might have fields 4
and 5 look something like

	:"=p" (is_zero)
	:"p" (a == 7))

and have support for using something like "%p0" and "%!p1" etc for
specifying predicates in the assembly string.  I don't know if you
already do something like this on ia64, or if gcc/ia64 even considers
the predicate bits to be independent registers. 

I don't know how much inline-asm has been written for ia64, but I
suspect that it could come in handy to let gcc select predicates too,
and not have to hardcode and clobber them (or whatever it is ia64 asms
do). 

		Linus

  parent reply	other threads:[~2001-11-20 17:17 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
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 [this message]
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='9te2tg$20d$1@penguin.transmeta.com' \
    --to=torvalds@transmeta.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