* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
*
Generally this looks like a fairly straightforward port replacement of
the original code with something essentially equivalent which is fine.
One issue is the new virtual finishTranslation function. Since
translation will happen very frequently (at least once a fetch), it's
best to avoid a
Hi everyone,
I've noticed a slight problem in using the branch predictor that's causing
it to update its state with the incorrect outcome of the branch. I'm
looking at O3CPU here. The problem comes in bpred_unit_impl.hh in
predict(). If the BTB doesn't supply a target address, then
Hi,
This question is mostly for Derek, but I figured that others at
Wisconsin may be able to answer it as well. I notice that the current
Ruby atomic support requires the sequencer to have direct access to its
associated L1 cache controller, rather than just via the mandatory
queue. Derek
Hi Tim,
Sorry for the delay in getting back to you... it's been a busy few
weeks. I had to go back and look at your earlier patches to make
sense of this one. I'll send some comments on those separately.
I'd say the main thing that could be cleaned up here is that you want
to extend the
This looks pretty straightforward to me...
On Mon, Nov 9, 2009 at 5:30 AM, Timothy M. Jones tjon...@inf.ed.ac.uk wrote:
# HG changeset patch
# User Timothy M. Jones tjon...@inf.ed.ac.uk
# Date 1257772283 0
# Node ID 861198113ecaf172b6d1e874cda4d13c92bdb38a
# Parent
Hi Brad,
Yes, the new atomic support also requires the sequencer to have a pointer to
the cache controller. The code that is in the repository now is a hack of
the slicc protocol code generator. The code is inserted in the middle of the
wakeup function in the cache controller. The new uncommited
Looking at just the part I've left below, it looks like you're
separating out the split vs non-split calls at the top, and then they
combine back into common functions at the bottom... I think it would
be cleaner if we got rid of the separate calls, and just used NULL
values for the split packets
Hi Tim,
It looks like you lost the initialization of isUncacheable... is that safe?
diff --git a/src/cpu/base_dyn_inst.hh b/src/cpu/base_dyn_inst.hh
--- a/src/cpu/base_dyn_inst.hh
+++ b/src/cpu/base_dyn_inst.hh
@@ -861,29 +871,14 @@
Request *req = new Request(asid, addr, sizeof(T),
Thanks Polina.
No rush, but when do you suspect you'll check in that code? Steve and I
have made a lot of progress on the unified configuration changes and I'm
hoping to send out another series of patches by the end of the week. I
want to make sure our changes merge well with your updates
Hey Brad-
I'll be checking it in asap. Unfortunately I didn't get a chance to do
it before thanksgiving but it's high on the list as soon as I get back.
-Derek
On Dec 1, 2009, at 5:27 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Thanks Polina.
No rush, but when do you suspect
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
*
12 matches
Mail list logo
