config: Cleanup CPU configuration

Information
Submitter:	Ali Saidi
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 9455:969ab2ed5cfa
---------------------------
config: Cleanup CPU configuration

The CPUs supported by the configuration scripts used to be
hard-coded. This was not ideal for several reasons. For example, the
configuration scripts depend on all CPU models even though only a
subset might have been compiled.

This changeset adds a new module to the configuration scripts that
automatically discovers the available CPU models from the compiled
SimObjects. As a nice bonus, the use of introspection allows us to
automatically generate a list of available CPU models suitable for
printing. This list is augmented with the Python doc string from the
underlying class if available.

Testing Done

Issue Summary

Description	From	Last Updated	Status
Why do we need this separately? Why not just add the list of configurations to help text for cpu-type?	Nilay Vaish	Jan. 14, 2013, 9:19 p.m.	Open
Can this not be part of CPU meta data?	Nilay Vaish	Jan. 14, 2013, 9:23 p.m.	Open
This special-casing is kind of ugly... is the basic problem that m5.objects only has C++-based objects? Is there a way ...	Steve Reinhardt	Jan. 23, 2013, 4:21 a.m.	Open

configs/common/Options.py (Diff revision 1)

Why do we need this separately? Why not just add the list of configurations to help text for cpu-type?

Show all issues

Andreas Sandberg Jan. 22, 2013, 10:54 p.m. (Jan. 22, 2013, 10:54 p.m.)

I'm pretty sure that the list of CPUs is already included in the output (unfortunately, I can't check that at the moment). The list CPU types option prints a more detailed list of CPU models, including their doc strings, and available aliases. The other option I considered was adding a magic 'help' CPU to the cpu-type parameter that would print this information.

configs/common/CpuConfig.py (Diff revision 1)

Can this not be part of CPU meta data?

Show all issues

Andreas Sandberg Jan. 22, 2013, 10:54 p.m. (Jan. 22, 2013, 10:54 p.m.)

There were two reasons for the current design:
 * The aliases were supposed to be a fall-back mechanism to provide backwards compatibility for existing scripts and CPUs and as such I felt that they were a part of the configuration script rather than the meta data.
 * The current system allows a tuple to be used instead of a single target. In that case, the first target that has been compiled is used. This was mainly intended to be used for virtualized CPUs where the 'kvm' alias could point to ('KvmArmCPU', 'KvmX86CPU') and the first available CPU would be used. Storing the alias as meta data would make this a bit trickier if you want to have a well defined search order when resolving the alias.

configs/common/CpuConfig.py (Diff revision 1)

Yes and no. It could be, but in that case if you old compiled in the simple CPUs you'd get an error instead of you need to have compiled the InOrderCPU...

configs/common/Options.py (Diff revision 1)

that are available (and compiled in), yes

In general I really love this.  The arm_detailed CPU object has always been pretty ugly IMO, so this change just makes the ugliness stand out even more because now there's less surrounding ugliness to obscure it ;).  Since you're not introducing any ugliness that wasn't already there, I'm OK with committing this as is and trying to solve the problem described below separately.

configs/common/CpuConfig.py (Diff revision 1)

This special-casing is kind of ugly... is the basic problem that m5.objects only has C++-based objects?  Is there a way to get a more comprehensive list of defined subclasses of BaseCPU or SimObject by constructing a list in the metaclass constructor, or something?

Show all issues

Ship It!

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Issue Summary

Status: Closed (submitted)