Messages in this thread | | | Date | Sat, 16 Sep 2023 23:11:32 +1000 | Subject | Re: [PATCH 09/17] m68k: Implement xor_unlock_is_negative_byte | From | Greg Ungerer <> |
| |
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
| |