[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32()

From: Cédric Le Goater
Subject: Re: [RFC PATCH-for-8.0 1/3] hw/ppc: Replace tswap32() by const_le32()
Date: Tue, 13 Dec 2022 17:53:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1

On 12/13/22 17:27, Richard Henderson wrote:
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.

But these are register default values. Endianness doesn't apply
there. Doesn't it ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]