Is the following correct? This is in the BaseCPU where it sets up the
data and instruction TLBs it's going to use and installs defaults. I'm
suspicious that this is actually installing a particular TLB to be the
default in all of the CPUs, or in other words all CPUs share the same
ITB and DTB. Am I crazy?
dtb = Param.SparcDTB(SparcDTB(), "Data TLB")
itb = Param.SparcITB(SparcITB(), "Instruction TLB")
Gabe
Gabe Black wrote:
> 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
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
