At a high level, I think this is a good direction. Specifically, I like the idea of making the ISA object a singleton for the simulation, or at least a member of the system, instead of one per CPU is great. We should probably make it per-system in case we want to support a simulation with multiple ISAs at some point in the future.
The TLBs should not be part of the ISA. These are just "caches" and should be ISA-agnostic just like the caches and memories are. While they may need to store ISA-specific data (e.g., PTEs, ASIDs, etc. are ISA-specific), the mechanism for a TLB is not ISA-specific. There was recently some push to go this direction, we need to finish this at some point. Cheers, Jason On Tue, Apr 27, 2021 at 6:12 PM Gabe Black via gem5-dev <[email protected]> wrote: > Hi folks. I can write up a more detailed document once there has been some > discussion about this, but I've been thinking about how the ISA object > works, and how the various ISA specific components of a CPU (decoder, TLBs, > interrupt object, ISA object itself) are hooked into each other. > > As of today, each context of execution has its own copy of the decoder, > the TLBs, the interrupt object (the local APIC in x86, basically ISA > specific interrupt handling logic), and the ISA object (home of MiscRegs, > some other stuff). > > My initial idea behind creating the ISA object was that it could be a home > for settings which affect the ISA itself, like what optional features were > enabled, what specific version of the ISA was in effect, etc. It made sense > to build that into the thing handling MiscRegs, since the value of and > behavior of those registers. > > All of these objects could, at least in theory, have configuration > parameters associated with them (size of the TLB, ISA parameters for > supported features, etc), and are generally represented by SimObjects which > are separately configured, and then plugged into the CPU in python. > > One problem with having the ISA object hold ISA specific configuration > comes from the fact that it's set up per thread, and there isn't a > centralized collection point for settings that should be common across > several threads. ARM currently solves this problem by creating a custom > System class, I believe the only one still in use in gem5 now, which holds > those settings and then distributes them to the ISA objects (I believe?). > This also creates a problem where there needs to be a custom System object, > and it needs to communicate with the ISA objects and keep each other in > sync. > > > What I think might make more sense is to adjust the role of the ISA object > a bit and expand it to be a single object which is assigned to a System. It > could then absorb all the ISA specific properties which are now part of the > ARM custom System class. Then, every time a ThreadContext is registered > with the System, the ISA object would have a chance to register its own > objects with it, including adding thread specific information like an > interrupts object, a decoder, a local object to handle MiscReg accesses, > etc., which could, as necessary, have ties back to the common ISA object. > > There would need to be a balance here between things which come from the > ISA object and things which do need to come from each CPU in the system, > like a way to set different TLB sizes for differently spec-ed cores for > instance. Maybe the ISA has some settings for those objects, and it sets > them post-facto when setting up a thread? > > Additionally, the new ISA regClassInfo array which describes what register > types there are and their properties could then be common to all threads > instead of duplicated in each ISA instance, and could be installed in the > ThreadContext by the ISA object, instead of having to be fetched from the > ISA object by everybody else as needed. > > You can probably tell that I haven't thought this out completely, but I > wanted to throw this out there for people to see and respond to, so please > see it and respond to it :-). > > Gabe > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
