On Fri, 4 Oct 2024 at 17:54, Philippe Mathieu-Daudé <phi...@linaro.org> wrote:
>
> On 4/10/24 18:41, Peter Maydell wrote:
> > On Fri, 4 Oct 2024 at 17:22, Philippe Mathieu-Daudé <phi...@linaro.org>
> > wrote:
> >>
> >> Introduce the CPUClass::is_big_endian() handler and its
> >> common default.
> >>
> >> Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
> >> ---
> >> include/hw/core/cpu.h | 3 ++-
> >> hw/core/cpu-common.c | 7 +++++++
> >> 2 files changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> >> index 04e9ad49968..22ef7a44e86 100644
> >> --- a/include/hw/core/cpu.h
> >> +++ b/include/hw/core/cpu.h
> >> @@ -150,6 +150,7 @@ struct CPUClass {
> >> ObjectClass *(*class_by_name)(const char *cpu_model);
> >> void (*parse_features)(const char *typename, char *str, Error
> >> **errp);
> >>
> >> + bool (*is_big_endian)(CPUState *cpu);
> >> bool (*has_work)(CPUState *cpu);
> >> int (*mmu_index)(CPUState *cpu, bool ifetch);
> >> int (*memory_rw_debug)(CPUState *cpu, vaddr addr,
> >
> > What does this actually mean, though? Arm for instance
> > has multiple different kinds of "big-endian" depending
> > on the CPU: both BE32 and BE8, and data-endianness not
> > necessarily being the same as instruction-endianness.
>
> This is to be used in the data bus (I was wondering whether using 'data'
> in the method name).
That sounds like what you actually want is (a non-compile-time
version of) TARGET_ENDIANNESS, which is not related to the
CPU's dynamic setting.
> > This series doesn't introduce any users of this new API.
> > It's hard to say without seeing what the intended use is,
> > but I would expect that probably they would want to be testing
> > something else, depending on what they're trying to do.
>
> I'm trying to split my branch in "~20 patches series";
> I should post example of API consumers in a few days.
>
> First conversion is the cpu_in/out() API in system/ioport.c,
> I'll try to post it ASAP so we can discuss there.
Yeah, I think we really need to look at the users, because
my current feeling is "we don't want this API at all,
the answer will always be to use something else".
I suspect for cpu_in/out the answer is "this API only
makes sense for x86, and whatever extent it's built
for anything else is accidental". We could probably
define it as always-little-endian.
-- PMM
