I believe the reason the UTB thing was done in that way was to try to match the current M5 infrastructure which require ITB and DTB pointers in every CPU model and have a few functions that hardcode (itb->___ or dtb->___).
If you dont derive UTB from both ITB and DTB you'll have a problem there with compatibility...hence a big headache because you have to figure out how to create a single object representing the UTB but then get ITB/DTB base pointers to use the UTB version. I wouldn't say delete the UTB because you need that to boot Full System MIPS and doesn't some other ISA use Unified TLB as well? I'm not sure every drop of FS MIPS code made it into the tree, but you definitely need that UTB or it definitely wont work. So what's the solution? Well, it really depends on how willing we are to change how we traditionally use the ITB and DTB in M5 (as has been discussed previously). On Fri, Mar 6, 2009 at 12:17 AM, nathan binkert <n...@binkert.org> wrote: > > Right, but you could have a flag that says "ifetch" (or an > > ifetch/read/write enum in place of the read/write flag we have now) to > > control that behavior. Then the current ITB would panic on a read or > > write request, and the DTB would panic on an ifetch, but a UTB could > > handle all of the above. > That's what I was suggesting with the extra parameter. So, it sounds > like this is the right approach. Gabe, can you help me implement it? > I'd think that it should be relatively easy, it probably just involves > mostly busy work. > > > Or more realistically we could just punt on having separate ITB and DTB > classes. > I personally think yes. I don't think it buys us very much. Maybe it > shortens the rope we give the users when they build a configuration, > but there's already way more than enough to allow a user to hang > themselves. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
