On Sat, Sep 16, 2023 at 11:11:32PM +1000, Greg Ungerer wrote:
> 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@xxxxxxxxxxxxx>
> > ---
> > 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
Well, that sucks. What do you suggest for Coldfire?
(Shame you didn't join in on the original discussion:
https://lore.kernel.org/linux-m68k/ZLmKq2VLjYGBVhMI@xxxxxxxxxxxxxxxxxxxx/ )
