Hi Andrea. I think this is likely because somebody wanted to sort of generalize the mechanisms in O3, but they didn't go through with it completely. You may need to move things around a bit, change where types are defined, etc., to make things really separable. I think the idea of a dynamic instruction is probably pretty general, but the specifics of what goes in it may be more specific to, for instance, a CPU which does renaming and needs to keep track of renamed register indices. It might make sense to make the dynamic instruction class truly specific to O3 and have something similar but distinct for other CPU models?
I haven't actually written a CPU model for gem5 before so this is all just my semi-informed opinion. Does anybody else have any suggestions? Gabe On Thu, Feb 28, 2019 at 8:43 AM Andrea Mondelli <[email protected]> wrote: > Hi > > In the src/cpu folder, the header base_dyn_inst.hh (shared by all the CPU > models) uses the PhysRegIdPtr object, that is a pointer to a PhysReg > implemented in the o3/comm.hh > There is a specific reason why the class BaseDynInst (defined for all > models) needs a model-specific object (defined only in the o3/ folder)? > > We could move the o3/comm.hh in the src/cpu folder, making the PhysReg a > generic and shared object. I suspect this was the initial intention. > > The problem happens when we try to add a new o3 CPU model with different > internal micro-architecture and: > - the generic o3 mechanism is still used > - the required modification is big enough to justify a new model instead > of an inherit from existing DerivO3 > In this situation, the new architecture (let's call it Deriv2O3 as an > example) with maybe a custom PhysReg implementation will be compiled with > the o3/comm.hh inclusion. This leads to a classic namespace error when in > the Deriv2O3 the user want to define a class with a name already used in > the o3 model. > > Another solution (my favorite) is to add the new custom o3 model in the > same o3 folder. In this case, we should have one subfolder for each model > (DerivO3, Deriv2O3 and so on), where existing common classes are used or > inherited from them (like the PhysReg implementation). > > What do you think it could be the best solution? > > Bests, > A. > > _______________________________________________ > 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
