> On Dec. 1, 2013, 9:36 p.m., Steve Reinhardt wrote: > > The flattenMiscReg stuff looks fine. I'm confused about the system pointer > > though; what's the need for it? (I assume that's forthcoming, but I'd like > > to know before I go along with adding the hooks here.) Also, why no system > > param in the python object for power, sparc, or x86? > > Ali Saidi wrote: > It certainly can be put in all of them. The need is that with the support > for ARMv8 we will be adding a set of options about what features you want > with the current running simulator (e.g. do you want to start in 64bit or > 32bit mode or do you want support for the security extensions?). This doesn't > make much sense to have an option on the ISA objects, because it's not > configurable per CPU, it's really a system thing and having CPUs with > different ideas about the feature set would be hugely problematic. So, we've > added a parameter to the ISA objects so from the ISA you can get to the > system and inquire if a certain feature is enabled. For this to work every > ISA needs to have a system object, although none of them use it for anything > other than ARM at the moment. > > Make sense?
Thanks for the explanation. Practically it makes sense, though philosophically it seems a bit weird... I still think of the ISA as really just a glorified namespace, or a policy template parameter (which is actually how it's used in some cases, I think). I don't even remember when we made it a SimObject, but presumably that was only so it could be manipulated in Python. So giving it state, even if it's just a pointer, seems strange to me... though I see that MIPS has already crossed that bridge. Cores have state, decoders have state, but an ISA is just a set of definitions. So to me a model where the enabled ISA feature set is a property of the core (or a subcomponent of the core), and all the cores inherit their settings from the System object, and somehow the ISA interfaces with the core to learn about the current settings, would be a better match to reality. However, I can believe that that's more awkward, and I can't say that I see a practical benefit, beyond the general principle that making things match reality to the extent possible is usually a good policy. So I'll register my unease, but I won't object ;). - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2108/#review4821 ----------------------------------------------------------- On Nov. 30, 2013, 4 p.m., Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2108/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2013, 4 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10009:2780f9f2ff7d > --------------------------- > arch, cpu: Add support for flattening misc register indexes. > > With ARMv8 support the same misc register id results in accessing different > registers depending on the current mode of the processor. This patch adds > the same orthogonality to the misc register file as the others (int, float, > cc). > For all the othre ISAs this is currently a null-implementation. > > Additionally, a system variable is added to all the ISA objects. > > > Diffs > ----- > > src/arch/alpha/AlphaISA.py 81d7551dd3be > src/arch/alpha/isa.hh 81d7551dd3be > src/arch/alpha/isa.cc 81d7551dd3be > src/arch/mips/MipsISA.py 81d7551dd3be > src/arch/mips/isa.hh 81d7551dd3be > src/arch/mips/isa.cc 81d7551dd3be > src/arch/power/isa.hh 81d7551dd3be > src/arch/sparc/isa.hh 81d7551dd3be > src/arch/x86/isa.hh 81d7551dd3be > src/cpu/checker/thread_context.hh 81d7551dd3be > src/cpu/inorder/thread_context.hh 81d7551dd3be > src/cpu/o3/thread_context.hh 81d7551dd3be > src/cpu/o3/thread_context_impl.hh 81d7551dd3be > src/cpu/simple_thread.hh 81d7551dd3be > src/cpu/thread_context.hh 81d7551dd3be > > Diff: http://reviews.gem5.org/r/2108/diff/ > > > Testing > ------- > > > Thanks, > > Ali Saidi > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
