* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby
passed.
*
On Fri, Mar 11, 2011 at 6:57 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
On Thu, 10 Mar 2011, Nilay Vaish wrote:
Creating root params
Creating root
Getting root
Done creating root
Creating system params
Getting system.physmem
Creating system
Getting system
Done creating system
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/561/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/562/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan
Binkert,
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/561/
---
(Updated 2011-03-11 09:33:50.616494)
Review request for Default, Ali Saidi, Gabe
These patches don't apply cleanly. Also, do these changes apply to the
fixed pipeline as well? The whole fixed/flexible thing grates on me because
there is so much code duplication in there. Can someone fix that?
Nate
On Fri, Mar 11, 2011 at 9:33 AM, Tushar Krishna
changeset 0dc6769af3a1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=0dc6769af3a1
description:
Ruby: Get rid of the dead ruby tester.
None of the code in the ruby tester directory is compiled or referred to
outside of that directory. This change
changeset 05d2937bacbf in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=05d2937bacbf
description:
Gems: Eliminate the now unused GEMS_ROOT scons variable.
diffstat:
src/mem/ruby/SConsopts | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diffs (13 lines):
changeset 5138d1e453f1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5138d1e453f1
description:
SCons: Stop embedding the mercurial revision into the binary.
This causes a lot of rebuilds that could have otherwise possibly been
avoided, and, more
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/561/#review940
---
Hi Tushar,
I have a few minor comments below, but my major question is
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/564/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/564/#review941
---
Can you comment on why the current code is broken in the commit message?
In the short run, I think the easiest way to break the cycle is to have the
network take the RubySystem object as a parameter instead of the other
way around, then add a registerNetwork() callback on RubySystem to let the
network give the system its pointer.
...
Finally, it occurs to me
On Fri, Mar 11, 2011 at 2:27 PM, Beckmann, Brad brad.beckm...@amd.comwrote:
Finally, it occurs to me that we avoid these issues to some extent in the
classic m5 memory hierarchy by using ports rather than parameters to set
up
inter-object connections; maybe we should consider extending or
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/564/
---
(Updated 2011-03-11 15:09:54.387169)
Review request for Default, Ali Saidi, Gabe
On 2011-03-11 12:21:35, Steve Reinhardt wrote:
Can you comment on why the current code is broken in the commit message?
It's not immediately obvious to me.
Updated description.
- Anthony
---
This is an automatically generated
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/569/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/572/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
Tony,
You'll want to do the description such that the 1st line is just the
summary line and then any detailed explanation goes on the following
lines.
So more like this on future patches/commits:
sim: Fixes Simulation.py to allow more than 1 core for standard switching.
This patch moves the
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/570/#review944
---
src/cpu/o3/bpred_unit_impl.hh
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/569/#review945
---
Why are you fixing up the fact that the CPU shouldn't have quiesced
On 2011-03-11 18:58:46, Gabe Black wrote:
Why are you fixing up the fact that the CPU shouldn't have quiesced instead
of preventing it from doing it in the first place? If the instruction is
being executed speculatively, you should mark it as non-speculative. If O3
is basing its
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/570/#review946
---
src/arch/arm/isa/insts/branch.isa
On 2011-03-11 18:58:46, Gabe Black wrote:
Why are you fixing up the fact that the CPU shouldn't have quiesced instead
of preventing it from doing it in the first place? If the instruction is
being executed speculatively, you should mark it as non-speculative. If O3
is basing its
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/570/#review949
---
src/arch/arm/isa/insts/branch.isa
On 2011-03-11 18:58:46, Gabe Black wrote:
Why are you fixing up the fact that the CPU shouldn't have quiesced instead
of preventing it from doing it in the first place? If the instruction is
being executed speculatively, you should mark it as non-speculative. If O3
is basing its
On 2011-03-11 18:58:46, Gabe Black wrote:
Why are you fixing up the fact that the CPU shouldn't have quiesced instead
of preventing it from doing it in the first place? If the instruction is
being executed speculatively, you should mark it as non-speculative. If O3
is basing its
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/570/#review953
---
src/cpu/o3/bpred_unit_impl.hh
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/570/#review955
---
src/arch/arm/predecoder.hh
http://reviews.m5sim.org/r/570/#comment1330
Hi Gabe,
Were you expecting these to be run automatically? Turns out they['re not, I
think because X86_FS is not listed as a valid build in util/regress.
Also, I'm not sure what our definition of quick is, but it might be worth
moving the atomic boot test to the quick category to make sure it
Yes, I wanted those to run automatically. Thanks for pointing that out.
I'll put together a review for that shortly. I'll move them both to
quick too since atomic and timing should take on the order of the same
amount of time.
Gabe
On 03/11/11 20:27, Steve Reinhardt wrote:
Hi Gabe,
Were you
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/573/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/573/
---
(Updated 2011-03-11 23:47:56.539632)
Review request for Default, Ali Saidi, Gabe
33 matches
Mail list logo
