On 3/10/24 23:37, Richard Henderson wrote:
On 10/3/24 14:34, Philippe Mathieu-Daudé wrote:
On 3/10/24 23:28, Richard Henderson wrote:
On 10/3/24 13:50, Philippe Mathieu-Daudé wrote:
On 30/9/24 09:34, Philippe Mathieu-Daudé wrote:
Introduce the ld/st_endian_p() API, which takes an extra
Alternatively we could use ld/st_te_p() since we already
have ld/st_he_p() for host endianness.
That's what ld/st_p are -- target-specific, in exec/cpu-all.h.
They are indeed *target-specific*, so we can not use them in
target-agnostic code.
By explicitly passing the endianness, ld/st_endian_p() API is
target-agnostic.
Then I miss whatever you meant here re st_te_p().
Care to elaborate?
I might had a bad start by adding this now endian-agnostic API
before removing the current endian-specific one.
Goal is instead of having machine code build twice, one for each
endianness, the same machine will be built once, but registering
2x machines. Endianness being a machine property, propagated to
the vCPUs and HW.
Instead of the following target-specific API:
#if TARGET_BIG_ENDIAN
#define stl_p(p, v) stl_be_p(p, v)
#else
#define stl_p(p, v) stl_le_p(p, v)
#endif
I'm suggesting this target-agnostic one:
#define stl_endian_p(big_endian, p, v) \
(big_endian) ? stl_be_p(p, v) : stl_le_p(p, v)
