Any luck?
nathan binkert wrote:
I'll try to figure this out, but I don't get it yet. I'll get an
older compiler going...
Nate
On Fri, Mar 6, 2009 at 10:48 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I'm heading out the door, but I just tried building X86_SE on the head
and it gave
OK,
so the solution should probably be move the ITB/DTB functions into one base
TLB and then let a unified TLB derive off of that...correct?
This would allow us the two standard ITB and DTB pointers we've been
using...but also avoid multiple inheritance issues as well.
On Fri, Mar 6, 2009 at
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
The ITB and DTB functions should be in -the- base TLB class I hope by
the end of the weekend at the latest. The UTB can then be assigned to
both ITB and DTB parameters and it should work.
Gabe
Korey Sewell wrote:
OK,
so the solution should probably be move the ITB/DTB functions into one
base
Gabe,
aren't those per-CPU python parameters? In other words, each CPU
instantiates it' own set of parameters in the config file through this
python interface...right?
On Fri, Mar 6, 2009 at 3:09 AM, Gabe Black gbl...@eecs.umich.edu wrote:
Is the following correct? This is in the BaseCPU where
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
On Fri, Mar 6, 2009 at 7:48 AM, nathan binkert n...@binkert.org wrote:
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
nathan binkert 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
That's odd... if it doesn't work that way, I'd consider that a bug.
On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I tried something like this before, and I don't think it works because
self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to
On Fri, Mar 6, 2009 at 10:19 AM, Gabe Black gbl...@eecs.umich.edu wrote:
nathan binkert wrote:
You have a VectorDistribution stat somewhere, and you're calling its
init() function with the first parameter as a float instead of an
integer. Nothing magic here, just apply normal debugging
I took a look at SouthBridge.py to see what you might have been
trying... were you trying to access an attribute of the param, like:
pic1 = Param.I8259(_pic1, Master PIC)
[...] Self.pic1.output [...]
I can see where that wouldn't work, as Self.pic1 is a proxy object
that merely says look
I'm heading out the door, but I just tried building X86_SE on the head
and it gave me the errors. I didn't think my changes caused them. I have
similar problems with ALPHA_SE, and I haven't tried any other targets.
gbl...@tater ~/m5/repos/m5.x86fs $ gcc -v
Using built-in specs.
Target:
That's odd... if it doesn't work that way, I'd consider that a bug.
On Fri, Mar 6, 2009 at 10:18 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I tried something like this before, and I don't think it works because
self.dtb is a paramdesc, not a SparcTLB. What Nate told me to do was to
I'll try to figure this out, but I don't get it yet. I'll get an
older compiler going...
Nate
On Fri, Mar 6, 2009 at 10:48 AM, Gabe Black gbl...@eecs.umich.edu wrote:
I'm heading out the door, but I just tried building X86_SE on the head
and it gave me the errors. I didn't think my changes
Nate,
I didn't directly implement that UTB part myself but I believe the mips utlb
has some different features than a normal tlb which allows them to share one
structure. I think that's part of their claim to fame so to speak...
Unfortunately, I can't think of the exact mechanism right now, but
That may be true, but none of it is actually in the UTB that we have
in our tree. All the UTB does is inherit from DTB and ITB and that's
it.
Although the UTB inheriting from the DTB and ITB seems pointless from the
outset, the way it was implemented is that if you can combine the
Seems like Gabe is doing this anyway (right?)
Yes.
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
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
On Thu, Mar 5, 2009 at 9:09 PM, nathan binkert n...@binkert.org 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
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
20 matches
Mail list logo
