Indeed, as Ali clarified, the CPU -> core is the fist part. The rest is just convenience "containers" pertaining to the object hierarchy and bundling. For example, I might want to create an AndreasCPU which is a SimObject that has a few cores + caches, and that Python and C++ class would enable me to create a better way of describing these hierarchies. I could also add stats to this new object that sees both the cores and caches.
Thanks, Andreas ________________________________________ From: [email protected] [[email protected]] On Behalf Of Ali Saidi [[email protected]] Sent: Wednesday, May 30, 2012 11:09 PM To: [email protected] Subject: Re: [gem5-dev] Core, CPU, cluster in gem5 I think what Andreas was proposing is to make the thing that executes instructions a core and add a new container class that is a CPU which includes pointers to the various caches the CPU is part of? Thanks, Ali On 30.05.2012 16:42, Steve Reinhardt wrote: > Well, when I was a kid, most CPUs didn't have caches, and "core" was what > old-timers used before they invented DRAM. ;-) So I guess I'm not all > that sympathetic to the objections to the current naming. > > In particular, I think CPU is a pretty ambiguous term, so I'm not keen on > saying that we currently have it wrong. That said, CPU is a pretty > ambiguous term, so I'm fine with renaming what we now call a CPU to be a > core, as I think that is less ambiguous. > > Beyond that, I'm a bit skeptical of being too rigid about other names. We > don't always have caches with our cores, e.g., when fat-forwarding with > AtomicSimple. There are other configurations where each CPU has its own > L2. And internally to AMD we have configurations that mimic Bulldozer core > pairs, which is yet another wrinkle. > > Also, I'm not clear on how renaming things makes the "get a pointer to my > L1" operation easier. > > In general I'm supportive of making configuration easier though, so I'm not > necessarily opposed to the idea... the benefit just isn't clear to me, > probably because I don't understand Andreas's use cases in detail. > > Steve > > On Wed, May 30, 2012 at 12:57 PM, Ali Saidi <[email protected]> wrote: > >> I think both symmetric and asymmetric systems need to be configurable. The latter is going to become more and more common in the future. Thanks, Ali Sent from my ARM powered mobile device On May 30, 2012, at 3:42 PM, Gabriel Michael Black <[email protected] [6]> wrote: >> >>> I'd like to see things still architected primarily around Cores (which >> is a better name, I think) than CPUs and for CPUs to be a configuration convenience primarily used at the python level. We don't want to force people into having CPUs set up in a particular way or with particular components by baking certain flavors of them into the rest of the simulator, but the idea in general seems pretty reasonable. Or in other words, I'd like to see this make things easier for the 90% who have normal looking CPUs while not making things any harder for the 10% who have some wacky scratch pad memory or an asymmetric cache hierarchy or an L2 on the CPU or whatever. >> >>> Gabe Quoting nathan binkert <[email protected] [1]>: >>> >>>> 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. This change also needs to be coupled with updates to how cores are enumerated, numbered, initialised, modelling of power states, etc. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] http://m5sim.org/mailman/listinfo/gem5-dev [4] mailto:[email protected] [5] http://m5sim.org/mailman/listinfo/gem5-dev [6] mailto:[email protected] [7] mailto:[email protected] [8] http://m5sim.org/mailman/listinfo/gem5-dev [9] mailto:[email protected] _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev -- 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
