On 12/13/22 10:21, Peter Maydell wrote:
On Tue, 13 Dec 2022 at 16:14, Richard Henderson
<richard.henderson@linaro.org> wrote:
On 12/13/22 10:10, Philippe Mathieu-Daudé wrote:
On 13/12/22 17:00, Richard Henderson wrote:
On 12/13/22 06:52, Philippe Mathieu-Daudé wrote:
Assuming the developers of commits 2c50e26efd ("powerpc: Add
a virtex5 ml507 refdesign board") and 4b387f9ee1 ("ppc: Add
aCube Sam460ex board") were testing on a little-endian setup,
they meant to use const_le32() instead of tswap32() here,
since tswap32() depends on the host endianness.
tswap depends on target endianness.
Yes, it depends on both host/target endianness. What I meant
is we shouldn't have system code depending on host endianness.
It compares host vs target endianness, to determine if a swap is needed. But
the real
dependency is target endianness.
It does seem odd, though. We have a value in host endianness
(the EPAPR_MAGIC constant, which is host-endian by virtue of
being a C constant). But we're storing it to env->gpr[], which
is to say the CPUPPCState general purpose register array. Isn't
that array *also* kept in host endianness order?
Yes indeed.
If so, then the right thing here is "don't swap at all",
So it would seem...
i.e. just "env->gpr[6] = EPAPR_MAGIC;". But that would imply
that the current code is setting the wrong value for the GPR
on little-endian hosts, which seems a bit unlikely...
... unless this board has only been tested on matching hosts.