Part of the problem is that it's really hard to find a place to split things were all dependencies are fulfilled, aka types are available for constants of that type, constants which define the range of enums are available, small functions that use types and constants are around, constants that are derived from small functions are there, etc., that you've split things into logically meaningful groups, and that it's split in such a way where that's true for all ISAs at the same time since other things expect to get certain definitions from certain files. I split things up a while ago into types.hh, utility.hh, isa_traits.hh, and x86_traits.hh/sparc_traits.hh for isa specific constants which works decently, but they tend to include each other which defeats the purpose. I don't have any good ideas for how to improve the situation, but it's a recurring problem and I would like to fix it some day.
Gabe Steve Reinhardt wrote: > I think keeping the register index type as part of the ISA makes > sense: in almost all conceivable cases a uint8_t is adequate, and when > you're packing several of these in each StaticInst it can really add > up to poor cache utilization, but forcing all future architectures to > have at most 256 regs is something you don't want to totally hardcode > either. > > If it is a big problems, it makes sense to me to break out > isa_traits.hh into a few separate files... not a "cloud of little > files" but maybe 2-3 separate files where one only defines the most > basic types (constants and things depending on system headers like > stdint.h) and another one or two that defines more complex types and > values (and thus includes more non-ISA headers). > > Steve > > On Sun, Sep 21, 2008 at 1:36 PM, Gabe Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Also, the loop was created by defining a generic ROM class that > most > ISAs would use that didn't do anything, and then including that and > "using" it in types.hh. The header file for the generic ROM needed a > function to return microops which meant it needed StaticInstPtr, which > meant it needed static_inst.hh, which includes isa_traits.hh which > causes a loop. I would really love to break the dependence between > StaticInstPtr and static_inst.hh, but I haven't been able to do > that in > the past. > > Gabe > > Gabe Black wrote: > > I just fought my way through another recursive include type > > situation while adding a microcode ROM to the CPUs. It seems > like there > > are just to many things that are useful in too many places in a few > > header files in each of the ISAs. If you include anything > outside of the > > ISA in one of those files, you've essentially included it in > most of the > > rest of the simulator, and at that point a loop is very likely to > > develop. I don't know of a good way to solve that problem, but I > have a > > few ideas on how to at least make it a little better. Some things we > > have as ISA defined types at the moment probably don't > absolutely need > > to be. For instance, all manner of register indexes could > probably just > > be uint32_t universally with no problems and minimal space > overhead. I > > don't think there are many instances of that and I don't like > the idea > > of removing that flexibility from the ISAs, so I'm not very excited > > about doing that. The other idea would be to create a cloud of > little > > header files which all defined exactly one thing. I think in > most cases, > > things outside the ISA really only need a few types and could > include > > each one individually without too much trouble. The biggest > problem here > > is that we'd end up with gobs of little files with way more > copyright > > information in them than actual code. Does anyone have any > suggestions? > > > > Gabe > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
