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

Reply via email to