I like the idea. Can we rename BaseCache to Cache while we're at it? I'm not going to volunteer, but the best way to make this work IMHO is to write a script that does the searching/replacing and make that one patch on its own. Then create another patch that fixes up any mistakes. This serves two purposes. First, you can just drop the old patch and regenerate it whenever you update your script, and second, all we need to do is review your script and the second patch. We've done this sort of thing many times in the past and to be honest, it's not that hard. The hardest part is dealing with the fact that scripts and stat names end up getting affected.
Nate > I am sure there are lots of ideas and opinions about the modelling of a core > vs CPU vs cluster, and I am keen to know how people feel about doing some > major re-naming and introduce some new levels of hierarchy in the world of > gem5 models. > > For a number of reasons (e.g. performance-monitoring, power modelling, trace > playback, etc) the current gem5 notation of a CPU is a bit misleading, as it > is actually only a core. Additionally, the separation of core and caches > complicates modelling of aspects that span the entire CPU (core + caches), > for example for the performance-monitoring. There have also been examples in > the past on the user and dev list of questions like "how do it get a pointer > to my L1", for very similar reasons. > > I am sure there are more reasons than I have listed here, and I would like to > propose a transition to a more well-defined hierarchy of core(s), CPU(s) and > clusters. A starting point would be to rename CPU -> core throughout the > codebase. After that we could introduce a SimObject CPU that would include > core(s) and L1(s), and also have getters for the latter. The next level again > would be a cluster, containing CPU(s) and caches. > > This change also needs to be coupled with updates to how cores are > enumerated, numbered, initialised, modelling of power states, etc. > > Ideas, feedback, and volunteers are appreciated :-) > > Andreas > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
