On Tue, 20 Nov 2018 17:15:11 PST (-0800), alistai...@gmail.com wrote:
On Fri, Nov 16, 2018 at 12:33 AM Richard Henderson
<richard.hender...@linaro.org> wrote:
On 11/15/18 11:35 PM, Alistair Francis wrote:
> +static void reloc_sbimm12(tcg_insn_unit *code_ptr, tcg_insn_unit *target)
> +{
> + intptr_t offset = (intptr_t)target - (intptr_t)code_ptr;
> + tcg_debug_assert(offset == sextract32(offset, 1, 12) << 1);
> +
> + code_ptr[0] |= encode_sbimm12(offset);
> +}
FYI, I have an in-flight patch for 4.0 that will make patch_reloc return a bool
for relocation success, which will move these asserts.
http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg02237.html
Thanks, I'll keep an eye on this.
> +static void reloc_call(tcg_insn_unit *code_ptr, tcg_insn_unit *target)
> +{
> + intptr_t offset = (intptr_t)target - (intptr_t)code_ptr;
> + tcg_debug_assert(offset == (int32_t)offset);
> +
> + int32_t hi20 = ((offset + 0x800) >> 12) << 12;
> + int32_t lo12 = offset - hi20;
> +
> + code_ptr[0] |= encode_uimm20(hi20);
> + code_ptr[1] |= encode_imm12(lo12);
> +}
> +
This is ok for patching during generation, but it is not ok for
tb_target_set_jmp_target from patch 9.
Will the riscv-32 compiler use a FSTD insn to implement atomic_set for 64-bit?
If not, you may be just better off using the indirect method.
I'm not sure. Is the indirect method just using atomic set, because
that is what I have now?
Per the memory model chapter (which is being ratified now), FSD is not atomic
on rv32i:
An FLD or FSD instruction for which XLEN<64 may also be decomposed into a
set of component memory operations of any granularity.
So they should not be used on RV32I hosts to provide atomicity, even if they
may be atomic on some microarchitectures.
