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]> 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 > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
