I'll keep both pointers then. I have all the non-ISA bits and X86 converted and I'm trying to test it, but I'm running into a compile error in the stats stuff. Nate?
cc1plus: warnings being treated as errors build/X86_SE/base/statistics.hh: In member function 'Stats::VectorDistribution& Stats::VectorDistribution::init(Stats::size_type, Stats::Counter, Stats::Counter, Stats::Counter)': build/X86_SE/base/statistics.hh:2498: warning: converting to 'Stats::size_type' from 'double' Gabe nathan binkert wrote: > Oh, I agree there. They may both point to the same thing (unified > case), but they may not. > > Nate > > >> Having two pointers in the CPU for the DTB and ITB is still a >> necessity. If you're trying to model separate structures you're going >> to need two of them. >> >> Ali >> >> >> On Mar 6, 2009, at 1:13 AM, Gabe Black wrote: >> >> >>> I think ITBs and DTBs are usually very similar differ in a few key >>> ways >>> like the nx (no execute) bit in x86 for example. In x86 the DTB and >>> ITB >>> classes are basically just wrappers around a common TLB with one >>> translate function, and the DTB's and ITB's version just call that >>> with >>> an extra parameter or two. This should generally work across other >>> ISAs >>> as far as I know. If the translate functions really are radically >>> different, there isn't much overhead in having them both in there and >>> just picking one or the other based on that parameter. I think even >>> the >>> generic TLB that's for SE implementations that don't have an ISA >>> specific TLB yet just looks things up in the page table no matter what >>> your translating. >>> >>> As far as whether to get rid of the separation between the ITB and >>> DTB I >>> think it's a good idea. I can't think of any benefit to having the >>> separation other than that it's already there, and while it hasn't >>> caused any other problems it prevents Korey from having a UTB >>> implementation. We'd likely want to give it parameters which let you >>> independently configure it's ITB and DTB (or UTB) personalities, but >>> that should be pretty easy. >>> >>> This should (knock on wood) be pretty easy to implement and I'd be >>> happy >>> to help. >>> >>> Gabe >>> >>> nathan binkert wrote: >>> >>>>> How different are ITBs and DTBs anyway? It seems like for a UTB >>>>> you'd >>>>> want a single object that handles both ifetch and data translations >>>>> using a common translate() method, not something that inherits from >>>>> two different classes. E.g., why not just derive it from TLB? >>>>> >>>>> >>>> The two translation functions are different because every ISA does >>>> some different things for instructions vs data. Think about >>>> something >>>> like the executable bit. >>>> >>>> >>>> >>>>> Philosophically, I agree... let's avoid virtual inheritance if at >>>>> all >>>>> possible. It's just not a good idea. >>>>> >>>>> >>>> Ok, so the question is, which of the other alternatives should we do? >>>> Gabe (mister TLB expert)? Korey (since this is mips code)? >>>> >>>> Nate >>>> _______________________________________________ >>>> 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 >> >> >> > _______________________________________________ > 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
