qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() functions
Date: Wed, 08 May 2019 10:34:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Eduardo Habkost <address@hidden> writes:

> On Mon, May 06, 2019 at 01:53:28PM +0200, Markus Armbruster wrote:
>> Eduardo Habkost <address@hidden> writes:
>> 
>> > This series adds a new CPUClass::class_name_format field, which
>> > allows us to delete 16 of the 21 *_cpu_class_by_name() functions
>> > that exist today.
>> 
>> Which five remain, and why?
>
> alpha_cpu_class_by_name:
> * Translates aliases based on alpha_cpu_aliases;
> * Falls back to "ev67" unconditionally
>   (there's a "TODO: remove match everything nonsense" comment).
>
> cris_cpu_class_by_name:
> * Translates "any" alias to "crisv32" if CONFIG_USER_ONLY.
>
> ppc_cpu_class_by_name:
> * Supports lookup by PVR if CPU model is a 8 digit hex number;
> * Converts CPU model to lowercase.
>
> superh_cpu_class_by_name:
> * Translates "any" alias to TYPE_SH7750R_CPU.
>
> sparc_cpu_class_by_name:
> * Replaces whitespaces with '-' on CPU model name.

I'm of course asking because I wonder whether we can dumb down this CPU
naming business to something simpler and more regular.

Let's review what we have.

For all <TARGET> in target/*:

* arm i386 lm32 m68k mips moxie openrisc riscv s390x s390x tricore
  unicore32 xtensa

  CPU type name format is <TARGET>_CPU_TYPE_NAME("%s"), which boils down
  to:

  - arm lm32 m68k moxie riscv s390x tricore unicore32 xtensa
    "%s-<TARGET>-cpu"

  - openrisc
    "%s-or1k-cpu"

  - i386
    "%s-x86_64-cpu" #ifdef TARGET_X86_64
    "%s-i386-cpu" #else

  - mips
    "%s-mips64-cpu" #ifdef TARGET_MIPS64
    "%s-mips-cpu" #else

  The %s gets replaced by the user's cpu model.

* hppa microblaze nios2 tilegx

  CPU type name format is <TARGET>-cpu.  The user's cpu model seems
  silently ignored.

* alpha cris ppc sh4 sparc

  No format, using ->class_by_name()

  - alpha

    CPU type name format is "%s-alpha-cpu".

    alpha_cpu_class_by_name() recognizes the full name, the full name
    without "-alpha-cpu" suffix, and a bunch of aliases.

  - cris

    CPU type name format is "%s-cris-cpu".

    cris_cpu_class_by_name() recognizes the name without the "-cris-cpu"
    suffix, plus "any" as alias for "crisv32-cris-cpu" #ifdef
    CONFIG_USER_ONLY (this is the default CPU type for machine
    "axis-dev88"; the other machine "none" has no default).

  - ppc

    CPU type name format is
    "%s-powerpc64-cpu" #ifdef TARGET_PPC64
    "%s-powerpc-cpu" #else

    ppc_cpu_class_by_name() recognizes the name without the suffix, plus
    the CPU type's PVR (8 digit hex number), plus a bunch of (case
    insensitive) aliases.

  - sh4

    CPU type name format is "%s-superh-cpu".

    superh_cpu_class_by_name() recognizes the name without the suffix,
    plus "any" as alias for "sh7750r-superh-cpu" (this is the default
    CPU type for machine "shix"; machines "r2d" defaults to "sh7751r",
    and "none" has no default).

  - sparc

    CPU type name format is
    "%s-sparc64-cpu" #ifdef TARGET_SPARC64
    "%s-sparc-cpu" #else

    sparc_cpu_class_by_name() recognizes the name without the suffix,
    mapping any spaces in the user's cpu model to '-'.

Observations:

* The CPU type name format is generally "%s-T-cpu", where T is either
  <TARGET> or <TARGET>64.

  Exceptions:

  - openrisc, sh4 uses or1k, superh instead.  Looks pointless to me.

  - i386 uses x86_64 instead of i38664.  Makes sense.

  - hppa, microblaze, nios2 and tilegx use CPU type name format "T-cpu",
    ignoring the user's cpu model.  These exceptions looks pointless to
    me.

* The user's CPU model is generally the "%s" part of the format.

  Exceptions:

  - alpha additionaly recognizes full type names.  If that's useful for
    alpha (I'm not sure it is), why isn't it useful for all other
    targets?

  - cris and sh4 additionaly recognize an "any" alias, cris only #ifdef
    CONFIG_USER_ONLY.

    Until PATCH 4, arm also recognizes an "any" alias #ifdef
    CONFIG_USER_ONLY.  PATCH 4 drops that, because it's redundant with
    the "any" CPU, which is a copy instead of an alias.  Sure we want to
    do have different targets do "any" in different ways?

    See aliases below.

  - ppc additionaly recognizes PVR aliases and additional (case
    insensitive) aliases.  Feels overengineered to me.  See aliases
    below.

  - sparc additionally recognizes aliases with ' ' instead of '-'.
    Feels pointless to me.  See aliases below.

* What about deprecating pointless exceptions?

* Aliases

  We have several targets roll their own CPU name aliases code.
  Assuming aliases are here to stay (i.e. we're not deprecating all of
  them): what about letting each CPU type specify a set of aliases, so
  we can recognize them in generic code?



reply via email to

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