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.