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
