On 27 April 2018 at 01:26, Richard Henderson
<richard.hender...@linaro.org> wrote:
> Given that this atomic operation will be used by both risc-v
> and aarch64, let's not duplicate code across the two targets.
>
> Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
> ---
> accel/tcg/atomic_template.h | 71
> +++++++++++++++++++++++++++++++++++++++++++++
> accel/tcg/tcg-runtime.h | 8 +++++
> tcg/tcg-op.h | 34 ++++++++++++++++++++++
> tcg/tcg.h | 8 +++++
> tcg/tcg-op.c | 8 +++++
> 5 files changed, 129 insertions(+)
> @@ -233,6 +270,39 @@ ABI_TYPE ATOMIC_NAME(add_fetch)(CPUArchState *env,
> target_ulong addr,
> ldo = ldn;
> }
> }
> +
> +/* These helpers are, as a whole, full barriers. Within the helper,
> + * the leading barrier is explicit and the trailing barrier is within
> + * cmpxchg primitive.
> + */
> +#define GEN_ATOMIC_HELPER_FN(X, FN, XDATA_TYPE, RET) \
> +ABI_TYPE ATOMIC_NAME(X)(CPUArchState *env, target_ulong addr, \
> + ABI_TYPE xval EXTRA_ARGS) \
> +{ \
> + ATOMIC_MMU_DECLS; \
> + XDATA_TYPE *haddr = ATOMIC_MMU_LOOKUP; \
> + XDATA_TYPE ldo, ldn, old, new, val = xval; \
> + smp_mb(); \
> + ldn = atomic_read__nocheck(haddr); \
I see you're using the __nocheck function here. How does this
work for the 32-bit host case where you don't necessarily have
a 64-bit atomic primitive?
> + do { \
> + ldo = ldn; old = BSWAP(ldo); new = FN(old, val); \
> + ldn = atomic_cmpxchg__nocheck(haddr, ldo, BSWAP(new)); \
> + } while (ldo != ldn); \
> + ATOMIC_MMU_CLEANUP; \
> + return RET; \
> +}
I was going to suggest that you could also now use this to
iimplement the currently-hand-coded fetch_add and add_fetch
for the reverse-host-endian case, but those don't have a leading
smp_mb() and this does. Do you know why those are different?
thanks
-- PMM
