RE: [RFC PATCH v3 26/34] Hexagon (target/hexagon) macros referenced in instruction semantics

[Taylor Simpson]

> -----Original Message-----
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Friday, August 28, 2020 7:17 PM
> To: Taylor Simpson <tsimpson@quicinc.com>; qemu-devel@nongnu.org
> Cc: philmd@redhat.com; laurent@vivier.eu; riku.voipio@iki.fi;
> aleksandar.m.mail@gmail.com; ale@rev.ng
> Subject: Re: [RFC PATCH v3 26/34] Hexagon (target/hexagon) macros
> referenced in instruction semantics
>
>
> Ah, so I see what you're trying to do with the merge thing, which had the
> host-endian problems.
>
> I think the merge stuff is a mistake.  I think you can get the semantics that
> you want with
>
> probe_read(ld_addr, ld_len)
> qemu_st(st_value, st_addr)
> qemu_ld(ld_value, ld_addr)
>
> In this way, all exceptions are recognized before the store is complete, the
> normal memory operations handle any possible overlap.

Following up on this...

1) We don't need to do the probe_read because the load has already happened at 
this point.

2) I'm not familiar with qemu_st/qemu_ld.  Are these shorthand for 
tcg_gen_qemu_st*/tcg_gen_qemu_ld*?  We can't actually do the store at this 
point because it would alter the memory before we are sure the packet will 
commit (i.e., there might be still be an exception raised by another 
instruction in the packet).

3) How important is it to support big endian hosts?  Would it be OK to put 
something like this to declare it isn't supported for Hexagon?
#if defined(HOST_WORDS_BIGENDIAN)
#error Hexagon guest not supported on big endian host
#endif

4) If the above is not OK, are the macros in bswap.h the correct ones to use?  
Is this pseudo-code correct?
store_val = le32_to_cpu(store_val);
load_val = le32_to_cpu(load_val);
<merge bytes>
/* store_val is dead so no need to convert back */
load_val = cpu_to_le32(load_val)


Thanks,
Taylor