On Thu, Aug 20, 2009 at 2:38 PM, nathan binkertn...@binkert.org wrote:
I'll comment on the rest of this discussion once I've had a chance to
read through it and think about it. My immediate thought is that while
a simplified manual roll over sort of mechanism would avoid using the
library
Actually the default=ALPHA_SE in Somayeh's specific command line
should be a complete no-op. All default=FOO build/BAR/* does is
that if there are no existing variable settings in build/variables/BAR
(from a previous build) then the initial settings are read out of
build_opts/FOO instead of
OK, I think I see what the problem might be. In
src/cpu/memtest/SConscript, we have:
if 'O3CPU' in env['CPU_MODELS']:
SimObject('MemTest.py')
So basically the MemTest object only gets compiled in if the O3CPU is
configured... that doesn't make any sense to me. I'm guessing it's
just a
The reason you don't get the error with m5.fast is because m5.fast
compiles out assertions. The issue is still there. (In general I
like to run regressions with m5.opt rather than m5.fast for this
reason.)
Using gdb is easy if you run m5 directly and not via the scons
regression framework
Scons arguments are case-sensitive, and default should be lower case.
I don't know that it's an official convention, but loosely speaking
the all-uppercase arguments are m5 configuration switches, while the
lowercase ones control scons (or the build process) itself (the only
other one I can think
On Tue, Aug 4, 2009 at 1:33 PM, nathan binkertn...@binkert.org wrote:
Now that the other GEM5 issues are mostly resolved (thanks everyone!), I
wanted to discuss the protocol directory issue in more detail. I'm
completely fine with recompiling all files when changing protocols. I would
On Mon, Aug 3, 2009 at 11:16 AM, Derek Howerderek.ho...@gmail.com wrote:
I do like the idea of a generic SequencerMsg class, but am a little
worried that it would ultimately be confusing. We can certianly split
DMARequestMsg into two different types, one for the request to the DMA
sequencer
changeset 50125d42559c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=50125d42559c
description:
Rename internal Request fields to start with '_'.
The inconsistency was causing a subtle bug with some of the
constructors where the params had the same name
changeset 9e35cdc95e81 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9e35cdc95e81
description:
Clean up some inconsistencies with Request flags.
diffstat:
4 files changed, 11 insertions(+), 20 deletions(-)
src/arch/arm/tlb.cc |2 +-
src/arch/sparc/tlb.cc |2
changeset 7ed8937e375a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7ed8937e375a
description:
Fix setting of INST_FETCH flag for O3 CPU.
It's still broken in inorder.
Also enhance DPRINTFs in cache and physical memory so we
can see more easily
Korey: I was going to fix this in inorder too, but there are two
places where Request objects are allocated (tlb_unit.hh and
cache_unit.cc) and I wasn't sure why there were two, if both needed to
be fixed, or what.
Also, I think with this flag in place we ought to be able to get rid
of the
On Fri, Jul 24, 2009 at 10:23 PM, Gabe Blackgbl...@eecs.umich.edu wrote:
We could also add a command line argument to the script. One thing to
note is that I think se.py is supposed to just be an example. I have the
impression it's often used exactly as is though, so that may not be a
valid
I'm not sure exactly what you're asking... you should instantiate
Debug from your configuration script. Once you do that, everything
else should just work.
I don't know enough about how lib-ruby is built or used to say more.
Steve
On Wed, Jul 22, 2009 at 1:33 PM, Somayeh
.
Gabe
Steve Reinhardt wrote:
I'm sorta just dreaming here, but I'm getting used to occasionally
browsing the code through repo.m5sim.org http://repo.m5sim.org,
and
it would be really nice if:
1. We had a web-based cross-reference (like lxr), so I don't have to
switch from firefox
On Tue, Jul 21, 2009 at 10:55 AM, Derek Howerd...@cs.wisc.edu wrote:
2) What's the best way to add multiple protocols to the regression
tests, so that all ruby related tests are run for each protocol?
Somayeh is almost done with MESI and we need to make sure it's tested.
I don't have a
Hi Derek,
Has Nate mentioned his cprintf package to you? It's basically a
type-safe C++ printf, which most of us find much nicer than C++ stream
I/O, particularly if you have to do a lot of formatting. I don't
consider it a major integration issue (like integrating statistics or
debugging), but
Yes.
On Mon, Jul 20, 2009 at 5:46 PM, Lisa Hsuh...@eecs.umich.edu wrote:
anyone get this?
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
___
m5-dev mailing list
Are you sure it's not you? I saw both patches and the third manual
email, and also replied (to the list) to your third email telling you
that I'd seen the first two.
Steve
On Sat, Jul 18, 2009 at 11:27 AM, Gabe Blackgbl...@eecs.umich.edu wrote:
I've tried sending a patch to this list three
There's no real control over ordering... I believe init() is called on
objects in the same order that they were constructed, but you don't have a
lot of control over the construction order (short of the fact that if B is a
parameter to A then B will be constructed first) and it's probably best not
The /z/m5 directory is on an internal U-M machine (zizzer), though the
regressions themselves are typically run on the Michigan simulation pool.
For this particular case, that shouldn't matter though; you should get the
same failure when you run the same test on a clean repository. If not, then
I'm sorta just dreaming here, but I'm getting used to occasionally browsing
the code through repo.m5sim.org, and it would be really nice if:
1. We had a web-based cross-reference (like lxr), so I don't have to switch
from firefox to an ssh session running cscope.
2a. Better yet, if there was a
of defining and initiating different objects are important for us, so we
should handle them too.
Somayeh
Steve Reinhardt wrote:
Hi Somayeh,
This sounds great. Unfortunately I don't know much about Ruby
configuration, but my expectation is that the first step in getting Ruby
configured in M5
On Thu, Jul 9, 2009 at 1:24 PM, nathan binkert n...@binkert.org wrote:
- You're guaranteed that any SimObject that is passed to you as a
parameter
has been constructed before your constructor is called, so that the
pointer
in the params struct is valid. Since init() hasn't been called
What we really need for x86 is more general locking. We've added a LOCKED
flag to the mem request, and the current x86 microcode uses this for locked
operations, where the semantics are that a load with the LOCKED flag (which
should lock the cache block) is always followed by a store with the
changeset a37f8971b271 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a37f8971b271
description:
Add ability to skip tests by adding 'skip' file to test dir,
and skip simple-timing-mp-ruby test for now (until we fix ruby atomics).
diffstat:
2 files changed, 3
Do we even use make_release.py any more? I'd think not since we're not
doing official releases. I noticed it the other day and was wondering if we
should just delete it.
On a separate but related note, we should update m5-stable at some point;
it's getting ridiculously out of date.
Steve
On
On Tue, Jun 30, 2009 at 2:14 AM, Jack Whitham jack-m5...@cs.york.ac.ukwrote:
I've only been half-following this thread, but I believe Gabe is right:
you
need StaticInst objects that claim to be different things
(branch/non-branch, conditional/unconditional, dependent/independent of
On Tue, Jun 30, 2009 at 3:24 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
This is fine, except it doesn't really address the op_rd and op_wb
issue, ie. having different code to read and write the register
arguments in the execute method. I'd like to have that fixed as soon
since
On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
That is true, but I think what he's talking about is when the CPSR
doesn't actually matter at all since the condition is always. I
don't know what the best way to do that would be, but one possibility
would
On Mon, Jun 29, 2009 at 7:07 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com:
On Mon, Jun 29, 2009 at 6:02 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
That is true, but I think what he's talking about is when the CPSR
Sorry for the slow reply... I'm traveling this week.
On Sun, Jun 21, 2009 at 10:30 AM, Gabe Black gbl...@eecs.umich.edu wrote:
To differentiate between branch/no branch that's actually along the
lines of what I want to do, which in retrospect doesn't really have
anything to do with what I was
Have you looked at how the Alpha ISA detects writes to R31 to generate
no-ops instead of regular instructions? Is there any reason that approach
(or a similar one) wouldn't work? You may not want two completely different
instructions like Alpha, but you could do the comparison with R15 in the
Within a real core, there's a lot of linkage between speculation, store/load
forwarding, memory disambiguation, enforcing consistency models, etc. such
that the load and store queues are tightly linked. Mostly this has to do
with out-of-order speculative execution. If you are only buffering
This looks like a pool glitch... there's no additional error info from qdo
(didn't we used to get more?) and I can't reproduce it.
Steve
On Sat, May 30, 2009 at 12:19 AM, Cron Daemon r...@zizzer.eecs.umich.eduwrote:
scons: *** [build/ALPHA_FS/base/loader/object_file.fo] Error 1
*
Looks like the EIO files failed to build because of stale references to
sim/host.hh, and the inorder compiles failed with a variety of errors (no
matching function, no declaration for X, etc.) like there's a missing header
file or something.
Steve
On Wed, May 20, 2009 at 3:25 AM, Cron Daemon
On Wed, May 20, 2009 at 7:22 AM, Korey Sewell ksew...@umich.edu wrote:
Otherwise, we'd have to figure out to not build InOrder for FS but
build it for SE.
That should be relatively easy. Right now it looks like
build_opts/ALPHA_FS is the only config that doesn't have an explicit setting
for
Does anyone know why m5 doesn't die when its stdout is closed? When
tracediff gives up, instead of the two m5 jobs dying, they just keep going
until you kill them explicitly. A typical program would die immediately on
the SIGPIPE.
You can verify this behavior by running m5 with tracing on and
When the script went to clean out the directory to do the scratch rebuild on
Saturday night the 'rm -rf' failed due to a permissions problem, which
aborted the script before the hg clone occurred. Subsequent runs failed
since there was no repo in place as they expected.
I hacked in a RUBY=True
Note that the Alpha inorder-timing test passed... I'm guessing that whatever
Korey did to get it going he did only to ALPHA_SE and not to MIPS_SE.
Tonight is the weekly rebuild everything from scratch regression so
there's no point in trying to fix it now, it should take care of itself.
Steve
On
I think I know what the problem is... to reset the build variables for
ALPHA_SE, you don't need to delete build/ALPHA_SE, you need to delete
build/variables/ALPHA_SE. Korey, if you delete that file then it should be
OK.
Steve
On Fri, May 15, 2009 at 12:24 AM, Cron Daemon
This all sounds great to me. I was never particularly fond of the host.hh
name either.
Steve
On Fri, May 15, 2009 at 11:34 AM, nathan binkert n...@binkert.org wrote:
I recently ran into a bug that would have been caught by the compiler
if we didn't have -Wno-sign-compare in our build. I've
On Thu, May 14, 2009 at 5:46 PM, Korey Sewell ksew...@umich.edu wrote:
Two things:
1) I see that there is an instruction flag in the Request Objects
called INST_FETCH but I didnt see anywhere in the code where this is
being utilized... Are there plans to use this information for maybe
like
zizzer (note the sender's email address)
On Wed, May 13, 2009 at 6:08 AM, Korey Sewell ksew...@umich.edu wrote:
See /z/m5/regression/regress-2009-05-13-03:00:01 for details.
Wher can I find this regression output message?
daystrom?
poolfs?
--
- Korey
Don't you have sudo access on zizzer?
On Wed, May 13, 2009 at 8:07 AM, Korey Sewell ksew...@umich.edu wrote:
On Wed, May 13, 2009 at 9:32 AM, Steve Reinhardt ste...@gmail.com
wrote:
zizzer (note the sender's email address)
I'm having a little trouble figuring out this error
changeset 29b7b7aba911 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=29b7b7aba911
description:
ruby: Check stderr and not stdin before hanging on an assert.
diffstat:
2 files changed, 3 insertions(+), 3 deletions(-)
src/mem/ruby/common/Debug.hh |4 ++--
IN ANY WAY OUT OF THE USE
+# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#
+# Authors: Steve Reinhardt
+
+import m5
+from m5.objects import *
+m5.AddToPath('../configs/common')
+
+
+cpu = DerivO3CPU(cpu_id=0)
+cpu.clock = '2GHz'
+
+system = System(cpu = cpu
changeset 8b240f106634 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8b240f106634
description:
ruby: Initial references for ruby regressions
diffstat:
63 files changed, 12397 insertions(+)
tests/quick/00.hello/ref/alpha/linux/simple-atomic-ruby/config.ini
I actually looked at the code a bit this time; and I have a hypothesis that
the problem arises from two similar but fundamentally different models of
bypassing potential event-based delays:
main() {
x_will_callback = x();
if (!x_will_callback) y();
}
x() {
if (...) {
You're right that the simple timing CPU is basically driven forward by the
responses to ifetch requests. The original idea (that I don't think has
changed) is to be the simplest, basically functional-only CPU that you can
have that is capable of driving the memory system in timing mode. So
I don't think I can respond to every point in this discussion, but here are
my general thoughts:
- Though they look superficially similar, the SPARC/MIPS single/double FP
accesses shouldn't necessarily be handled the same way as x86
partial-register writes. They're both awkward and ugly, but
On Thu, Apr 30, 2009 at 2:54 PM, Korey Sewell ksew...@umich.edu wrote:
Actually it does because -all- floating point registers are then 32 bits.
The existence of 64 bit registers is just an illusion the instructions
provide by gluing two 32 bit registers together internally.
I understand
Thanks for catching this... I've wanted a command-line option to enable this
on a few occasions in the past. Could you add the code to enable the option
in fs.py, or better yet, find someplace common to stick it like
Simulation.py so that it just automatically works for both?
I don't see where
OK, thinking about this a bit more, it seems like the root of the problem is
that the timing translation is calling the callback right away instead of
deferring it to a later cycle. I assume this only happens on a TLB miss for
a store conditional? Is there any other path by which the completeAcc
Whew, I don't check my email for one afternoon and you guys make me pay for
it...
I'm still curious about the possibility of using an event to call the
completeAcc() callback in the case where the translation fails on a store
conditional. This solution seems particularly attractive to me if it's
On Tue, Apr 28, 2009 at 1:19 PM, nathan binkert n...@binkert.org wrote:
2) You split the translation if the address crosses blocks. It seems
that it'd be better to check to see if the access crosses pages, not
blocks to save the extra work.
I was told I should use the peer block size
On Tue, Apr 28, 2009 at 4:43 PM, Gabe Black gbl...@eecs.umich.edu wrote:
I'm not sure if it will be hugely better. I'd have to just do it and see
how it comes out, I suppose. Wouldn't scheduling an event be similar to
what I have, just using the event queue instead of the new packet
pointer?
If it works, then I'm all for it... thanks for taking a look at it.
Steve
On Fri, Apr 24, 2009 at 12:45 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
So does anyone object to this change? It's not strictly necessary and
I haven't tested it beyond the m5threads regression, but it's a
I think Gabe sums it up pretty nicely. Another way to phrase the same idea
is that m5-dev is really for m5 *infrastructure* development.
I hadn't understood before why sometimes we get user questions on m5-dev,
but Javier's explanation makes sense. Unlike most open-source projects, I
think it's
changeset 5af0a83d9021 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5af0a83d9021
description:
request: reorganize flags to group related flags together.
diffstat:
1 file changed, 21 insertions(+), 19 deletions(-)
src/mem/request.hh | 40
Wow, that is concerning... glad you noticed it! I don't recall discussing
this discrepancy specifically before. I know there are some minor issues in
double-counting faulting instructions, and that for EIO compatibility
sometimes we have to make some special adjustments, but these are all pretty
there is so many different accounting for commits,
they ALL probably arent being tagged for the special cases.
So maybe what's needed is:
sim_insts
and
committed_per_thread (if SMT)
On Thu, Apr 23, 2009 at 12:05 PM, Steve Reinhardt ste...@gmail.comwrote:
OK, it's really a fairly superficial
changeset 52a5e1c63380 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=52a5e1c63380
description:
Minor tweaks for future Ruby compatibility.
diffstat:
2 files changed, 4 insertions(+), 4 deletions(-)
configs/common/Simulation.py |6 ++
src/mem/physical.hh
changeset 21f6eaab12df in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=21f6eaab12df
description:
Set up m5threads tests on classic (non-ruby) memory system.
Just one test (40.m5threads-test-atomic) is set up for now.
These tests require that the m5threads
changeset ca0915f8d86d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ca0915f8d86d
description:
request: split public and private flags into separate fields.
This frees up needed space for more public flags. Also:
- remove unused Request accessor
changeset 9af6fb59752f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9af6fb59752f
description:
mem: use single BadAddr responder per system.
Previously there was one per bus, which caused some coherence problems
when more than one decided to respond.
changeset 82c377317a86 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=82c377317a86
description:
Update stats for new single bad-address responder.
Mostly just config.ini updates, though the different response
latency for bad addresses caused very minor
Hi Gabe,
Can you describe the semantics of this flag more precisely, and then put
that description in a comment? Looking at your subsequent commits, I'm
inferring that the first LOCKED access locks a block, and the next LOCKED
access unlocks it. Of course there are a number of other
I'm in favor of changing isLlsc() to isLLSC()... since it's an acronym, the
mixed-case looks funny to me.
Steve
On Sun, Apr 19, 2009 at 5:07 AM, Gabe Black gbl...@eecs.umich.edu wrote:
changeset e141cc7896ce in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e141cc7896ce
Black gbl...@eecs.umich.edu wrote:
Steve Reinhardt wrote:
Hi Gabe,
Can you describe the semantics of this flag more precisely, and then
put that description in a comment? Looking at your subsequent
commits, I'm inferring that the first LOCKED access locks a block, and
the next LOCKED
mailto:gbl...@eecs.umich.edu wrote:
Quoting Steve Reinhardt ste...@gmail.com mailto:ste...@gmail.com
:
On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black
gbl...@eecs.umich.edu mailto:gbl...@eecs.umich.edu wrote:
You should also be sure to test starting
On Sat, Apr 18, 2009 at 9:05 AM, nathan binkert n...@binkert.org wrote:
So since this would be an O3 simulation, then that would mean I would
want all CPU flags, the TLB, the Cache, and also the Exec flag.
How is that different from All?
Yea, that's my question too (from yesterday
I think I did miss something... why are you holding off?
On Sat, Apr 18, 2009 at 5:34 PM, Gabe Black gbl...@eecs.umich.edu wrote:
Just to make sure everybody noticed, nobody should be waiting for me
right now. If you want to commit, go for it. Also, I think I'm going to
take advantage of
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, 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
for when I get back to the code.
On Thu, Apr 16, 2009 at 12:52 AM, Steve Reinhardt ste...@gmail.com
wrote:
I see now, I missed that little change buried at the bottom.
I recall that condition about unconditional PC-relative branches finding
out
in decode that their target
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()
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
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
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 /z/repo
help clarify the code.
Gabe
Steve Reinhardt wrote:
In the situation where I was running into problems, the FullO3CPUImpl::
readArchFloatRegInt() function which I fixed in the patch was being
called from O3ThreadContextImpl::readFloatRegBits(), and that
function calls flattenFloatIndex
Those tests passed on April 5 and took 395 and 440 seconds on zizzer,
respectively. So (1) they must have broken since then and (2) if they're
taking longer than 10 minutes or so (depending on where you're running them)
they're definitely broken.
Steve
On Thu, Apr 16, 2009 at 9:08 PM, Gabe
Yes, I can see now why you want to clean this up...
So more concretely, it seems like I need to add TheISA::NumIntRegs in
somewhere; is readArchFloatRegInt() the right place to do it? I think so,
since (I believe) the input to that function is an architectural FP register
index (0-31) while
changeset 137a2b89eed4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=137a2b89eed4
description:
configs: Allow M5_CPU2000 env var to set CPU2K binary path.
It would be nice to have a more comprehensive mechanism
but this is a big improvement over
a path environment to search for binary files. I could
easily create a .m5/path.py script that works with it so people could
change it for their machines.
Nate
On Wed, Apr 15, 2009 at 12:57 PM, Steve Reinhardt
steve.reinha...@amd.com wrote:
changeset 137a2b89eed4 in /z/repo/m5
details
changeset 007c36616f47 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=007c36616f47
description:
Get rid of the Unallocated thread context state.
Basically merge it in with Halted.
Also had to get rid of a few other functions that
called
changeset be16ad28822f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=be16ad28822f
description:
ThreadState: initialize status to Halted in constructor.
This provides a common initial status for all threads independent
of CPU model (unlike the prior
, 2009 at 3:17 PM, Ali Saidi sa...@umich.edu wrote:
What do these changes do to CPU idle vs. busy stats? Are they correct?
Ali
On Apr 15, 2009, at 3:29 PM, Steve Reinhardt wrote:
changeset 007c36616f47 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=007c36616f47
OK, the following patch appears to work... unless I hear an objection, I'll
commit it later tonight or tomorrow.
Steve
--
diff -r 663e33ff46c9 src/cpu/o3/cpu.cc
--- a/src/cpu/o3/cpu.cc Wed Apr 15 13:56:45 2009 -0700
+++ b/src/cpu/o3/cpu.cc Wed Apr 15 15:42:57 2009 -0700
@@ -1283,7
I'm confused... this patch looks like it pretty much just inserts a bunch of
DPRINTFs (plus the seemingly mistaken inclusion of a whitespace change in
mips/isa/decoder.isa).
I don't know anything specific about the O3 predictor, but it makes sense
that the history is updated speculatively in
out the 2nd one from happening and things work again.
The reason why you get a mispredict in decode is I think the fetching
scenario behind an unconditional PC-relative branch. You wont know exactly
which direction to go until after decode.
On Wed, Apr 15, 2009 at 11:44 PM, Steve Reinhardt
The syscall instruction is marked as serializing, and it's up to the CPU
model to look at that flag and do whatever (if anything) is necessary to
make sure that any register or memory changes that happen in the syscall are
seen by the subsequent instructions--typically this means flush the
calls.
MIPS had system calls marked as IsSerializing which (from grep'ing
around) happens to be a flag that isn't even used in the code anymore
(delete?!).
On Tue, Apr 14, 2009 at 1:57 PM, Steve Reinhardt ste...@gmail.com wrote:
The syscall instruction is marked as serializing, and it's up
On Tue, Apr 14, 2009 at 1:43 PM, Korey Sewell ksew...@umich.edu wrote:
Well, I think the problem was (other than me just messing up), was that
nowhere in the O3 code does it use IsSerializing anymore. Matter of fact,
nowhere in any CPU model is that used anymore. (grep -rn IsSerializing
Thanks for the clarification, Korey. I was just in the middle of
composing an email asking for exactly this kind of explanation.
There's still one aspect that confuses me though: why does translation
need to be separated out of xc-read() and xc-write()? The model for
all the other CPUs is that
Why all the new methods on FloatRegFile? Are they used only by the in-order
CPU? I'm just surprised they weren't there already.
Also, is this change below really necessary?
diff -r 0555121b5c5f -r d4ff65e87a0b src/cpu/inorder/resources/tlb_unit.cc
--- a/src/cpu/inorder/resources/tlb_unit.cc
It would be nice to try and organize these shared files rather than just
throwing them all in the src/cpu directory... that dir is already getting a
little crowded. IMO, the only files that really belong there are ones that
describe common base classes (BaseCPU, ThreadContext, etc.). How about a
I haven't looked at Korey's code in that much detail yet, but in general the
execution-phase operations have had this kind of structure:
1. CPU model calls StaticInst method with pointer to execution context
(e.g., DynInst)
2. StaticInst method does what it needs to do, calling back into the
The right command to update the reference outputs would be:
scons update_ref=y
build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder.timing
Let me know if it doesn't work after you do that.
Also note that scons won't rerun the test if none of its dependencies (e.g.,
the m5 binary) has
, when we make changes that will affect regressions, do we typically
want to commit the change and the regression-updates in different
changesets?
On Thu, Apr 9, 2009 at 11:40 PM, Steve Reinhardt ste...@gmail.com wrote:
The right command to update the reference outputs would be:
scons
701 - 800 of 977 matches
Mail list logo
