Re: [PATCH 09/17] m68k: Implement xor_unlock_is_negative_byte

Greg Ungerer
2023-09-16T13:15:35Z

On 16/9/23 04:36, Matthew Wilcox (Oracle) wrote:
> Using EOR to clear the guaranteed-to-be-set lock bit will test the
> negative flag just like the x86 implementation. This should be
> more efficient than the generic implementation in filemap.c. It
> would be better if m68k had __GCC_ASM_FLAG_OUTPUTS__.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> arch/m68k/include/asm/bitops.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/m68k/include/asm/bitops.h b/arch/m68k/include/asm/bitops.h
> index e984af71df6b..909ebe7cab5d 100644
> --- a/arch/m68k/include/asm/bitops.h
> +++ b/arch/m68k/include/asm/bitops.h
> @@ -319,6 +319,20 @@ arch___test_and_change_bit(unsigned long nr, volatile unsigned long *addr)
> return test_and_change_bit(nr, addr);
> }
>
> +static inline bool xor_unlock_is_negative_byte(unsigned long mask,
> + volatile unsigned long *p)
> +{
> + char result;
> + char *cp = (char *)p + 3; /* m68k is big-endian */
> +
> + __asm__ __volatile__ ("eor.b %1, %2; smi %0"

The ColdFire members of the 68k family do not support byte size eor:

CC mm/filemap.o
{standard input}: Assembler messages:
{standard input}:824: Error: invalid instruction for this architecture; needs 68000 or higher (68000 [68ec000, 68hc000, 68hc001, 68008, 68302, 68306, 68307, 68322, 68356], 68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `eor.b #1,3(%a0)' ignored

Regards
Greg

> + : "=d" (result)
> + : "di" (mask), "o" (*cp)
> + : "memory");
> + return result;
> +}
> +#define xor_unlock_is_negative_byte xor_unlock_is_negative_byte
> +
> /*
> * The true 68020 and more advanced processors support the "bfffo"
> * instruction for finding bits. ColdFire and simple 68000 parts