Linux M68K Architecture development
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: linux-m68k@lists.linux-m68k.org
Subject: clear_bit_unlock_is_negative_byte
Date: Thu, 20 Jul 2023 20:27:39 +0100	[thread overview]
Message-ID: <ZLmKq2VLjYGBVhMI@casper.infradead.org> (raw)

I'm looking to implement clear_bit_unlock_is_negative_byte() on every
architecture so we can delete the ifdeffery around maybe-we-have-it
and remove the simple implementation from filemap.c.  Here's what I've
come up with for m68k:

+static inline bool clear_bit_unlock_is_negative_byte(unsigned int nr,
+               volatile unsigned long *p)
+{
+       char result;
+       char mask = 1 << nr;    /* nr guaranteed to be < 7 */
+
+       __asm__ __volatile__ ("eori %1, %2; smi %0"
+               : "=d" (result)
+               : "i" (mask), "o" (*p)
+               : "memory");
+       return result;
+}

It compiles, so I feel Very Pleased With Myself, since I haven't written
m68k assmbly in 25 years.  But I have questions.

First, m68k is big-endian, so I suspect I'm accessing the wrong byte.
Should something in there be adding 3 to 'p'?  Better to do it in the
asm, or in the constraints so the compiler can see it?

Second, have I properly communicated to the assembler that this is
a byte-size operation, and it needs to check bit 7 and not bits 15 or 31
to set the negative flag?

Third, can this be done better?  x86 has __GCC_ASM_FLAG_OUTPUTS__
so it doesn't need the equivalent of the SMI instruction to move the
condition to an output variable; it can just tell the compiler that
the N flag communicates the result that it's looking for.  Does m68k
have __GCC_ASM_FLAG_OUTPUTS__ or did nobody do that work yet?

Fourth, we could do this is with ANDI instead of EORI.  It's mildly
safer, but we really shouldn't have two threads clearing the lock bit
that race with each other.  We can't do it with BCLR because that
doesn't set the N flag.  If we do that, we'd need to invert the mask.

Appreciate your time looking at this.

             reply	other threads:[~2023-07-20 19:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-20 19:27 Matthew Wilcox [this message]
2023-07-20 22:37 ` clear_bit_unlock_is_negative_byte Michael Schmitz
2023-07-21  1:12   ` clear_bit_unlock_is_negative_byte Michael Schmitz
2023-07-21  1:32     ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-21  1:43       ` clear_bit_unlock_is_negative_byte Michael Schmitz
2023-07-21 17:03         ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-21 22:07           ` clear_bit_unlock_is_negative_byte Michael Schmitz
2023-07-22  6:24         ` clear_bit_unlock_is_negative_byte Andreas Schwab
2023-07-22 14:45           ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-22 15:26             ` clear_bit_unlock_is_negative_byte Andreas Schwab
2023-07-22 15:38               ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-21  6:34 ` clear_bit_unlock_is_negative_byte Andreas Schwab
2023-07-21  8:57   ` clear_bit_unlock_is_negative_byte Brad Boyer
2023-07-21  9:18     ` clear_bit_unlock_is_negative_byte Andreas Schwab
2023-07-21 11:59   ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-21 12:52     ` clear_bit_unlock_is_negative_byte Andreas Schwab
2023-07-21 20:29     ` clear_bit_unlock_is_negative_byte Brad Boyer
2023-07-22  3:42       ` clear_bit_unlock_is_negative_byte Matthew Wilcox
2023-07-22 23:49         ` clear_bit_unlock_is_negative_byte Brad Boyer
2023-07-23  1:08           ` clear_bit_unlock_is_negative_byte Michael Schmitz

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=ZLmKq2VLjYGBVhMI@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-m68k@lists.linux-m68k.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