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
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
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
On Thu, Mar 5, 2009 at 5:10 PM, Gabriel Michael Black gbl...@eecs.umich.edu
wrote:
The change is simple enough that I'll just describe it. This deals
solely with the simple CPU, so if your trying to use O3, for example,
it won't help you directly. The code here:
This is the mail system at host daystrom.m5sim.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete
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
I'm running into this with gem5 now (the problem with canceled or
aborted runs) and I think I've tracked down a possible explanation...
basically running the test and comparing the outputs are set up as two
separate tasks in scons, and the only thing the output comparison task
is dependent on is
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
Hi Ali!
So, I did run the seg-faulting boot in gdb and realized that in
./build/SPARC_FS/arch/sparc/tlb.cc line 1264 was seg-faulting because it was
reading bits(data,12,8) and not checking to see that they are within the
range of the total thread contexts available and then it was trying to
You probably need to swizzle those bits as well.. turn id 3 into id 1.
Perhaps then it will work.
Ali
On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
Hi Ali!
So, I did run the seg-faulting boot in gdb and realized that in ./
build/SPARC_FS/arch/sparc/tlb.cc line 1264 was seg-faulting
Can you tell me where you see id 3?
Polina
On Fri, Mar 6, 2009 at 3:49 PM, Ali Saidi sa...@umich.edu wrote:
You probably need to swizzle those bits as well.. turn id 3 into id 1.
Perhaps then it will work.
Ali
On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
Hi Ali!
So, I did run
Oh, never mind, I understand what you are saying. I will do that.
On Fri, Mar 6, 2009 at 3:49 PM, Ali Saidi sa...@umich.edu wrote:
You probably need to swizzle those bits as well.. turn id 3 into id 1.
Perhaps then it will work.
Ali
On Mar 6, 2009, at 4:44 PM, Polina Dudnik wrote:
Hi
To give everyone a heads up, I'm going to have family visiting
from March 11th until the 30th and will have very little time for M5
if any. If there's anything important that needs to be done soon, it
will need to be done before Tuesday.
Gabe
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
25 matches
Mail list logo
