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
