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
