qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 01/30] target/sh4: Use cmpxchg for movco


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [PATCH v3 01/30] target/sh4: Use cmpxchg for movco
Date: Tue, 18 Jul 2017 22:19:06 +0200
User-agent: NeoMutt/20170113 (1.7.2)

On 2017-07-18 10:02, Richard Henderson wrote:
> As for other targets, cmpxchg isn't quite right for ll/sc,
> suffering from an ABA race, but is sufficient to implement
> portable atomic operations.
> 
> Signed-off-by: Richard Henderson <address@hidden>
> 
> ---
> V2: Clear lock_addr in rte, do_interrupt, syscall entry, & signal delivery.
>     Fix movli to tollerate overlap between R0 and REG(B11_8).
> ---
>  target/sh4/cpu.h       |  3 ++-
>  linux-user/main.c      |  1 +
>  linux-user/signal.c    |  2 ++
>  target/sh4/helper.c    |  2 +-
>  target/sh4/translate.c | 72 
> +++++++++++++++++++++++++++++---------------------
>  5 files changed, 48 insertions(+), 32 deletions(-)

I still believe that for the system case, we should implement the
behaviour described in the manual, that is setting ldst to 1 in movli
and clearing it in an interrupt. Otherwise the plainly silly following
instruction sequence will give different results than on real silicon:

    movli.l   @r1,r0
    add       #4, r1
    movco.l   r0, @r1

Yes, this is plainly silly to use movli/movco to copy data, but we have
also implemented silly behaviour for other CPUs. For the user case it's
different, we don't have real choice, plus we know that it will be used
to execute linux binaries, which are more likely to have a sane usage of
atomic instructions.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]