OK So I finally figured out what's wrong here and admittedly I'm a
bit apprehensive of the universal (all ISA) fix will be but we'll see.
So let me explain the situation from the top:
(1) In the Decode of O3, an unconditional pc-relative branch is
resolved and the prediciton history table is
I can see where this patch solves the immediate problem, but it's not clear
it's not just a band-aid. The real question is what is the code supposed to
be doing?
The larger context in FullO3CPUImpl::init() is this:
for (int tid=0; tid number_of_threads; tid++) {
#if FULL_SYSTEM
Yea, that's helpful. I guess I am looking for a more fine-grained
control of things in terms of show me all flags that have to do with
me running O3CPU.
You would think O3CPUAll would be enough, but there are some base
flags that are relevant (e.g. TLB or Cache) that I would want to
include.
I
You could just cobble everything you want together into a composite flag and
call it O3CPUAll.then not only would it be easy to see but easy to turn
on.
On Fri, Apr 17, 2009 at 11:47 AM, Korey Sewell ksew...@umich.edu wrote:
Yea, that's helpful. I guess I am looking for a more fine-grained
Yea, at some point it becomes subjective (and dependent on the specific
problem you're tracking down) to say what's related. If O3CPUAll isn't
sufficient, what is there in All that is too much noise to deal with?
Basically the only thing in All that I find truly annoying is the Event
stuff, so if
I'm not sure what you mean. You just make up a traceflag calle O3CPUAll, or
even KoreysO3Flags , you could make whatever you want, it won't affect
anyone.
See src/cpu/SConscript and look at the CompoundFlags - that's how Exec
works, it's a collection of lots of other flags.
On Fri, Apr 17, 2009
Thanks for digging into this in more detail, Korey. It sounds to me like
maybe the problem is that MIPS is setting predPC to the branch target, when
(to account for the delay slot) it ought to be leaving predPC as PC+4 and
setting predNPC to be the branch target. That way if the prediction turns
I'm not sure what you mean. You just make up a traceflag calle O3CPUAll, or
even KoreysO3Flags , you could make whatever you want, it won't affect
anyone.
See src/cpu/SConscript and look at the CompoundFlags - that's how Exec
works, it's a collection of lots of other flags.
But committing
Yea, that's helpful. I guess I am looking for a more fine-grained
control of things in terms of show me all flags that have to do with
me running O3CPU.
We don't actually keep that kind of information anywhere. All
traceflags are currently global.
Nate
Oh, definitely not a commit of KoreysO3, that would obviously have to stay
in one's patch tree...but a reasonable commit with a reasonable name that is
usedul - I think wouldn't be so bad.
Lisa
On Fri, Apr 17, 2009 at 1:35 PM, nathan binkert n...@binkert.org wrote:
I'm not sure what you mean.
changeset fb895218046e in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=fb895218046e
summary: add a hack to ingore a return value even when gcc was told that we
shouldn't
diffstat:
3 files changed, 6 insertions(+), 3 deletions(-)
eio/eio.cc|4 ++--
On Fri, Apr 17, 2009 at 9:42 AM, Gabe Black gbl...@eecs.umich.edu wrote:
So the idea is that we only call initCPU() if the thread is in the
Suspended state (I believe there's a more straightforward way to code
that!), which the comment implies is because we only want to call
initCPU()
I'm not an expert on this code, but I think it's preventing excessively
restarting the CPU if you do a switchover or resume from a checkpoint.
Yea, that's exactly my assumption too, but I'd feel much better if someone
could explain in detail why it's necessary rather than just leaving it in
On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert n...@binkert.org wrote:
I'm not an expert on this code, but I think it's preventing excessively
restarting the CPU if you do a switchover or resume from a checkpoint.
Yea, that's exactly my assumption too, but I'd feel much better if
Quoting Steve Reinhardt ste...@gmail.com:
On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert n...@binkert.org wrote:
I'm not an expert on this code, but I think it's preventing excessively
restarting the CPU if you do a switchover or resume from a checkpoint.
Yea, that's exactly my
On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
You should also be sure to test starting from a checkpoint which I
believe is different from a switchover, although I'm not sure.
It shouldn't be different from O3's perspective; we always restore from a
Quoting Steve Reinhardt ste...@gmail.com:
On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
You should also be sure to test starting from a checkpoint which I
believe is different from a switchover, although I'm not sure.
It shouldn't be different from
But you could checkpoint O3 and then restore directly, couldn't you?
No, we currently don't support that. We also don't support
checkpointing the caches.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
No, we don't support that. O3 is too complicated, has too much state to
checkpoint, so we only checkpoint and restore AtomicCPU, then move into the
desired CPU model post-checkpoint.
On Fri, Apr 17, 2009 at 7:26 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt
changeset fc2e234b4404 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fc2e234b4404
description:
o3, inorder: fix FS bug due to initializing ThreadState to Halted.
For some reason o3 FS init() only called initCPU if the thread state
was Suspended, which
OK, this code passes the long regressions (for me, anyway), and I also did
an ad-hoc test of checkpoint/resume/switchover and fast-forward and those
seemed to go OK as well.
Steve
On Fri, Apr 17, 2009 at 4:59 PM, Steve Reinhardt steve.reinha...@amd.comwrote:
changeset fc2e234b4404 in
Just to make sure I'm interpreting this correctly, I should be able to
suspend a halted CPU to go directly to suspended, correct? The simple
CPU asserts in that case. The attached patch fixes it, but I want to
make sure I'm not getting the status stuff turned around again.
Gabe
Lisa Hsu wrote:
22 matches
Mail list logo
