On 03/11/2016 17:51, Richard Henderson wrote: >>> Well, tas_test "runs without error with this change", I suppose it fails >>> before? In other words, is this patch enough to run multithreaded sh4 >>> programs with qemu-user? >> >> It should,:the problem was reported by Adrian (cc:) while compiling ghc >> in qemu-sh4, but I have just tested the functionality with the softmmu >> version, not the atomicity. >> >> Adrian, could you test this patch? > > It's a start, but sh4 has an interesting scheme to implement atomic > sequences via special values in the stack pointer. E.g. xchg is > > mova 1f, r0 > mov sp, r1 > mov #(0f-1f), sp > 0: mov.l mem, out > mov.l in, mem > 1: mov r1, sp > > which is only atomic if you've got a UP kernel and have code in your > interrupt entry point that recognizes the small negative value in SP to > reset the PC as necessary.
UP kernel = no sane way to implement this in user-mode qemu? Doing pattern matching on negative sp moves and the instructions in between is probably not sane, even though GCC always has: - mov/mov for exchange - mov/cmpeq/bf/mov for compare-and-swap - mov/mov/op/mov for fetch-and-foo - mov/mov/and/not/mov for fetch-and-nand - mov/op/mov for foo-and-fetch - mov/and/not/mov for nand-and-fetch Another possibility is to treat the load as a LL and the store as a SC (implemented in turn with cmpxchg+branch if it fails). cmpxchg spans two basic blocks, so maybe one also needs to look at r0 and sp in cpu_get_tb_cpu_state... Anyhow this patch seems like a bugfix. Paolo > For SH4A, there are proper load-locked/store-condition insns, but prior > to that TAS was the only truly atomic insn.
