Re: [m5-dev] changeset in web-graphics: Add existing graphics
Ok, I changed things just a little bit. I renamed the repo (it's new, so you'll have to re-clone) to ssh://h...@m5sim.org/web-graphics It now covers the entire graphics directory. I committed the three graphics that we already had, and added a commit hook to e-mail everyone. Nate > changeset dc14d18b399d in /z/repo/web-graphics > details: web-graphics?cmd=changeset;node=dc14d18b399d > description: > Add existing graphics > > diffstat: > > InstructionExecution.png | 0 > X86DecoderGeneration.png | 0 > X86PredecoderStateMachine.png | 0 > 3 files changed, 0 insertions(+), 0 deletions(-) > > diffs (6 lines): > > diff -r -r dc14d18b399d InstructionExecution.png > Binary file InstructionExecution.png has changed > diff -r -r dc14d18b399d X86DecoderGeneration.png > Binary file X86DecoderGeneration.png has changed > diff -r -r dc14d18b399d X86PredecoderStateMachine.png > Binary file X86PredecoderStateMachine.png has changed > ___ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in web-graphics: Add existing graphics
changeset dc14d18b399d in /z/repo/web-graphics details: web-graphics?cmd=changeset;node=dc14d18b399d description: Add existing graphics diffstat: InstructionExecution.png |0 X86DecoderGeneration.png |0 X86PredecoderStateMachine.png |0 3 files changed, 0 insertions(+), 0 deletions(-) diffs (6 lines): diff -r -r dc14d18b399d InstructionExecution.png Binary file InstructionExecution.png has changed diff -r -r dc14d18b399d X86DecoderGeneration.png Binary file X86DecoderGeneration.png has changed diff -r -r dc14d18b399d X86PredecoderStateMachine.png Binary file X86PredecoderStateMachine.png has changed ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in web-graphics: Add existing graphics
changeset dc14d18b399d in /z/repo/web-graphics details: web-graphics?cmd=changeset;node=dc14d18b399d description: Add existing graphics diffstat: InstructionExecution.png |0 X86DecoderGeneration.png |0 X86PredecoderStateMachine.png |0 3 files changed, 0 insertions(+), 0 deletions(-) diffs (6 lines): diff -r -r dc14d18b399d InstructionExecution.png Binary file InstructionExecution.png has changed diff -r -r dc14d18b399d X86DecoderGeneration.png Binary file X86DecoderGeneration.png has changed diff -r -r dc14d18b399d X86PredecoderStateMachine.png Binary file X86PredecoderStateMachine.png has changed ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron /z/m5/regression/do-regression quick
I pushed in patch that imports math in MI_example.py -- Nilay On Mon, 28 Mar 2011, Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby FAILED! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: This patch supports cache flushing in MOESI_hammer
changeset a8d64545cda6 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a8d64545cda6
description:
This patch supports cache flushing in MOESI_hammer
diffstat:
configs/example/ruby_random_test.py|9 +-
src/cpu/testers/rubytest/Check.cc | 35 +++
src/cpu/testers/rubytest/Check.hh |1 +
src/cpu/testers/rubytest/RubyTester.cc |3 +-
src/cpu/testers/rubytest/RubyTester.hh |2 +
src/cpu/testers/rubytest/RubyTester.py |1 +
src/mem/packet.cc |4 +-
src/mem/packet.hh |4 +
src/mem/protocol/MOESI_hammer-cache.sm | 312 +++-
src/mem/protocol/MOESI_hammer-dir.sm | 135 +-
src/mem/protocol/MOESI_hammer-msg.sm |3 +
src/mem/protocol/RubySlicc_Exports.sm |1 +
src/mem/ruby/system/RubyPort.cc| 14 +-
src/mem/ruby/system/Sequencer.cc | 12 +-
14 files changed, 508 insertions(+), 28 deletions(-)
diffs (truncated from 1084 to 300 lines):
diff -r 1333bd6cc2eb -r a8d64545cda6 configs/example/ruby_random_test.py
--- a/configs/example/ruby_random_test.py Mon Mar 28 10:49:36 2011 -0500
+++ b/configs/example/ruby_random_test.py Mon Mar 28 10:49:45 2011 -0500
@@ -82,7 +82,14 @@
#
# Create the ruby random tester
#
-tester = RubyTester(checks_to_complete = options.checks,
+
+# Check the protocol
+check_flush = False
+if buildEnv['PROTOCOL'] == 'MOESI_hammer':
+check_flush = True
+
+tester = RubyTester(check_flush = check_flush,
+checks_to_complete = options.checks,
wakeup_frequency = options.wakeup_freq)
#
diff -r 1333bd6cc2eb -r a8d64545cda6 src/cpu/testers/rubytest/Check.cc
--- a/src/cpu/testers/rubytest/Check.cc Mon Mar 28 10:49:36 2011 -0500
+++ b/src/cpu/testers/rubytest/Check.cc Mon Mar 28 10:49:45 2011 -0500
@@ -59,6 +59,10 @@
initiatePrefetch(); // Prefetch from random processor
}
+if (m_tester_ptr->getCheckFlush() && (random() & 0xff) == 0) {
+initiateFlush(); // issue a Flush request from random processor
+}
+
if (m_status == TesterStatus_Idle) {
initiateAction();
} else if (m_status == TesterStatus_Ready) {
@@ -124,6 +128,37 @@
}
void
+Check::initiateFlush()
+{
+
+DPRINTF(RubyTest, "initiating Flush\n");
+
+int index = random() % m_num_cpu_sequencers;
+RubyTester::CpuPort* port =
+safe_cast(m_tester_ptr->getCpuPort(index));
+
+Request::Flags flags;
+
+Request *req = new Request(m_address.getAddress(), CHECK_SIZE, flags,
curTick(),
+ m_pc.getAddress());
+
+Packet::Command cmd;
+
+cmd = MemCmd::FlushReq;
+
+PacketPtr pkt = new Packet(req, cmd, port->idx);
+
+// push the subblock onto the sender state. The sequencer will
+// update the subblock on the return
+pkt->senderState =
+new SenderState(m_address, req->getSize(), pkt->senderState);
+
+if (port->sendTiming(pkt)) {
+DPRINTF(RubyTest, "initiating Flush - successful\n");
+}
+}
+
+void
Check::initiateAction()
{
DPRINTF(RubyTest, "initiating Action\n");
diff -r 1333bd6cc2eb -r a8d64545cda6 src/cpu/testers/rubytest/Check.hh
--- a/src/cpu/testers/rubytest/Check.hh Mon Mar 28 10:49:36 2011 -0500
+++ b/src/cpu/testers/rubytest/Check.hh Mon Mar 28 10:49:45 2011 -0500
@@ -58,6 +58,7 @@
void print(std::ostream& out) const;
private:
+void initiateFlush();
void initiatePrefetch();
void initiateAction();
void initiateCheck();
diff -r 1333bd6cc2eb -r a8d64545cda6 src/cpu/testers/rubytest/RubyTester.cc
--- a/src/cpu/testers/rubytest/RubyTester.ccMon Mar 28 10:49:36 2011 -0500
+++ b/src/cpu/testers/rubytest/RubyTester.ccMon Mar 28 10:49:45 2011 -0500
@@ -40,7 +40,8 @@
: MemObject(p), checkStartEvent(this),
m_checks_to_complete(p->checks_to_complete),
m_deadlock_threshold(p->deadlock_threshold),
-m_wakeup_frequency(p->wakeup_frequency)
+m_wakeup_frequency(p->wakeup_frequency),
+m_check_flush(p->check_flush)
{
m_checks_completed = 0;
diff -r 1333bd6cc2eb -r a8d64545cda6 src/cpu/testers/rubytest/RubyTester.hh
--- a/src/cpu/testers/rubytest/RubyTester.hhMon Mar 28 10:49:36 2011 -0500
+++ b/src/cpu/testers/rubytest/RubyTester.hhMon Mar 28 10:49:45 2011 -0500
@@ -99,6 +99,7 @@
void printConfig(std::ostream& out) const {}
void print(std::ostream& out) const;
+bool getCheckFlush() { return m_check_flush; }
protected:
class CheckStartEvent : public Event
@@ -134,6 +135,7 @@
int m_deadlock_threshold;
int m_num_cpu_sequencers;
int m_wakeup_frequency;
+bool m_check_flush;
};
inline std::ostream&
diff -r 1333bd6cc2eb -r a8d64545cda6 src/cpu/testers/rubytest/RubyTester.py
--- a/src/cpu/testers/rubytest/RubyTester.pyMon Mar 28 10:49:36 2011 -0500
+++ b/src/cpu/testers/rubytest/RubyTester.pyMon Mar 28 10:49:45 2011 -0500
@@ -36,3 +36,4 @@
checks_to_
[m5-dev] changeset in m5: Config: Import math in MI_example.py
changeset 1333bd6cc2eb in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=1333bd6cc2eb description: Config: Import math in MI_example.py diffstat: configs/ruby/MI_example.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r 832ae3727c2b -r 1333bd6cc2eb configs/ruby/MI_example.py --- a/configs/ruby/MI_example.pySat Mar 26 22:24:36 2011 -0700 +++ b/configs/ruby/MI_example.pyMon Mar 28 10:49:36 2011 -0500 @@ -27,6 +27,7 @@ # # Authors: Brad Beckmann +import math import m5 from m5.objects import * from m5.defines import buildEnv ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst
> On 2011-03-03 20:41:09, Ali Saidi wrote: > > Please don't ship this until I have a chance to try it, I just want to make > > sure it doesn't break ARM_FS/O3. > > Korey Sewell wrote: > Sure, I'd welcome a go of things from some other folks to test if I > haven't introduced something quirky. > > After there is some commentary, I'll make sure to run the full > regressions before committing this because as we all know BaseDynInst is a > pretty fundamental part of M5. > > Also, I'll be posting an update to this diff soon that will make the > setRegOperand pure virtual (I mistakenly thought those were > templated member functions in the first go-round). > > Ali Saidi wrote: > Anything happen with your update diff? If you could verify it passes the > arm/o3 full system regression I just committed and then I'll give it a go on > a bunch more tests. > > Korey Sewell wrote: > Gabe made a good point about the virtual function overhead on the > commonly used set*Operand functions and I've just been waffling on whether to > even make those pure virtual or not. > > However, I'll go ahead and take a hard look at this again , run the > regressions, and post an update tomorrow so we can move on with this > potential change. > > Korey Sewell wrote: > The ARM regressions pass with this patch. Feel free to do further testing. > > Ali Saidi wrote: > What about the virtual function overhead? > > Korey Sewell wrote: > This patch I posted didn't have any virtual functions in it. I was > speculating whether or not we should add the pure virtual functions to > solidify the DynInst interface. > > I went ahead and added the virtual functions in a separate patch, ran the > ARM_FS o3 regressions 2x on the same machine, and then took the inst/second > from the generated m5 stat files: > o3-timing (current): 115133, 115406 > o3-timing (this patch): 115011, 115709 > o3-timing (this patch w/pure virtual functions on BaseDynInst > read/set*Operands): 114368,113055 > > Although running something 2x isn't anything that could be called > "thorough", it looks like adding the virtual functions incurs a overhead of > about 1K-2K inst/second, while the patch as currently constructed gives about > the same performance as the code that doesn't split the o3-specific code out > of BaseDynInst. > > Since few people actually work on the internals of the CPU models anyway, > it's probably better to go with the patch submitted (pending further ARM-FS > testing) than to sacrifice the small amount of performance for an interface > that would rarely, if ever, be extended past the Inorder/O3 models. Can I assume that this patch is OK to push (assuming a final run of all the o3-regression tests pass???) - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/529/#review932 --- On 2011-03-01 13:49:24, Korey Sewell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/529/ > --- > > (Updated 2011-03-01 13:49:24) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > cpu: split o3-specific parts out of BaseDynInst > The bigger picture goal is that I want to get the InorderDynInst class > derived from the > BaseDynInst, since there is no need to replicate a lot of useful code already > defined > in BaseDynInst (e.g. microcode identification, etc.) and Inorder can take > advantage > of common code that handles microcode and other features that other ISAs need. > > But to do this, there are a lot of o3-specific things that are in > BaseDynInst, that I pushed to > O3DynInst in this patch. Book-keeping variables that handle the IQ,LSQ,ROB > are unnecessary in > the base class but generic variables that will work across CPUs (IsSquashed, > IsCompleted, etc.) > are kept in the base class. > > The upside is more consistency across the simple models (branch prediction > and instruction > identification are all in one common place). > > I really wanted to define pure virtual functions for read/write(to memory) > and the > setRegOperand, but virtual functions in a templated class is a > no-no and > I couldn't get around that (suggestions?). > > Also, I'd rather not use the "this->" pointer all over the place to access > member variables of > the templated Base class, but it had to be done. > > Other than those quirks, simulator functionality should stay the same as the > O3 Model always references > the O3DynInst pointer and the InOrder model doesnt currently make use of the > base dyn inst. class. > (but it will be easier to derive from
[m5-dev] Cron /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby FAILED! scons: *** [build/POWER_SE/kern/linux/linux.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/branch.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/mem.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/integer.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/condition.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/floating.fo] Error 1 scons: *** [build/POWER_SE/arch/power/insts/static_inst.fo] Error 1 scons: *** [build/POWER_SE/arch/power/pagetable.fo] Error 1 scons: *** [build/POWER_SE/arch/power/utility.fo] Error 1 scons: *** [build/POWER_SE/arch/power/tlb.fo] Error 1 scons: *** [build/POWER_SE/arch/power/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/linux/process.fo] Error 1 scons: *** [build/POWER_SE/arch/power/decoder.fo] Error 1 scons: *** [build/POWER_SE/arch/power/atomic_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/o3_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/arch/power/timing_simple_cpu_exec.fo] Error 1 scons: *** [build/POWER_SE/sim/pseudo_inst.fo] Error 1 scons: *** [build/POWER_SE/sim/faults.fo] Error 1 scons: *** [build/POWER_SE/sim/stat_control.fo] Error 1 scons: *** [build/POWER_SE/sim/tlb.fo] Error 1 scons: *** [build/POWER_SE/sim/system.fo] Error 1 scons: *** [build/POWER_SE/sim/process.fo] Error 1 scons: *** [build/POWER_SE/sim/syscall_emul.fo] Error 1 scons: *** [build/POWER_SE/mem/physical.fo] Error 1 scons: *** [build/POWER_SE/mem/page_table.fo] Error 1 scons: *** [build/POWER_SE/mem/translating_port.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/base.fo] Error 1 scons: *** [build/POWER_SE/mem/cache/prefetch/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/exetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/nativetrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/inteltrace.fo] Error 1 scons: *** [build/POWER_SE/cpu/pc_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/static_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/quiesce_event.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple_thread.fo] Error 1 scons: *** [build/POWER_SE/cpu/thread_state.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/atomic.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/timing.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/bpred_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/simple/base.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/base_dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/commit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/cpu_builder.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/decode.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/fetch.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/iew.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/free_list.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/dyn_inst.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/lsq_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/inst_queue.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/mem_dep_unit.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename_map.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rename.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/thread_context.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/scoreboard.fo] Error 1 scons: *** [build/POWER_SE/cpu/o3/rob.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/ras.fo] Error 1 scons: *** [build/POWER_SE/cpu/pred/btb.fo] Error 1 scons: *** [build/POWER_SE/base/remote_gdb.fo] Error 1 * 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/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/
