[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 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-atomic passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. = Statistics differences =* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/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-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. *
Re: [m5-dev] Review Request: trace: reimplement the DTRACE function so it doesn't use a vector
On 2010-12-21 22:44:19, Steve Reinhardt wrote: The name trace flags doesn't bother me, but debug flags is OK too. I wouldn't want to be more generic than that though. I was thinking of adding a command line option for --debug-flags, but leaving the --trace-flags one there as well. Sound reasonable? On 2010-12-21 22:44:19, Steve Reinhardt wrote: src/base/trace.hh, line 95 http://reviews.m5sim.org/r/352/diff/1/?file=5661#file5661line95 If you're going to put the 'using namespace' here, why not delete 'Trace::' where it's currently used? I can't honestly say why I did that. I'll get rid of it. It could have had something to do with overloaded scope, but I'll at least try. The using namespace stuff is there so the flags are in scope and you don't have to do Trace:: before each flag. I could document that :) - Nathan --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/#review564 --- On 2010-12-21 08:36:19, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/ --- (Updated 2010-12-21 08:36:19) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- trace: reimplement the DTRACE function so it doesn't use a vector One question I have about this stuff is if I should call everything trace, or debug? This diff is somewhat confused about that (some things are trace and some things are debug) and I expect to fix it. We always called this stuff trace flags in the past, but we I would like to start using these flags for other things. For example, turning on and off debugging breakpoints of different kinds. Execution tracing is a totally different mechanism but does use trace flags. My personal inclination is that trace flag is probably a bad name, but perhaps debug is a bad name too. Just call it flags? Or SimFlags? Diffs - src/SConscript 4a3bddd74f36 src/arch/alpha/interrupts.hh 4a3bddd74f36 src/arch/alpha/kernel_stats.cc 4a3bddd74f36 src/arch/alpha/linux/process.cc 4a3bddd74f36 src/arch/alpha/linux/system.cc 4a3bddd74f36 src/arch/alpha/process.cc 4a3bddd74f36 src/arch/alpha/remote_gdb.cc 4a3bddd74f36 src/arch/alpha/stacktrace.hh 4a3bddd74f36 src/arch/alpha/system.cc 4a3bddd74f36 src/arch/alpha/tlb.cc 4a3bddd74f36 src/arch/alpha/vtophys.cc 4a3bddd74f36 src/arch/arm/faults.cc 4a3bddd74f36 src/arch/arm/isa.hh 4a3bddd74f36 src/arch/arm/isa.cc 4a3bddd74f36 src/arch/arm/isa/includes.isa 4a3bddd74f36 src/arch/arm/nativetrace.cc 4a3bddd74f36 src/arch/arm/predecoder.cc 4a3bddd74f36 src/arch/arm/process.cc 4a3bddd74f36 src/arch/arm/remote_gdb.cc 4a3bddd74f36 src/arch/arm/stacktrace.hh 4a3bddd74f36 src/arch/arm/tlb.cc 4a3bddd74f36 src/arch/mips/faults.cc 4a3bddd74f36 src/arch/mips/isa.cc 4a3bddd74f36 src/arch/mips/isa/includes.isa 4a3bddd74f36 src/arch/mips/linux/process.cc 4a3bddd74f36 src/arch/mips/locked_mem.hh 4a3bddd74f36 src/arch/mips/process.cc 4a3bddd74f36 src/arch/mips/stacktrace.hh 4a3bddd74f36 src/arch/mips/tlb.cc 4a3bddd74f36 src/arch/power/process.cc 4a3bddd74f36 src/arch/power/stacktrace.hh 4a3bddd74f36 src/arch/power/tlb.cc 4a3bddd74f36 src/arch/sparc/interrupts.hh 4a3bddd74f36 src/arch/sparc/isa.cc 4a3bddd74f36 src/arch/sparc/isa/includes.isa 4a3bddd74f36 src/arch/sparc/process.cc 4a3bddd74f36 src/arch/sparc/remote_gdb.cc 4a3bddd74f36 src/arch/sparc/stacktrace.hh 4a3bddd74f36 src/arch/sparc/tlb.cc 4a3bddd74f36 src/arch/sparc/ua2005.cc 4a3bddd74f36 src/arch/sparc/vtophys.cc 4a3bddd74f36 src/arch/x86/faults.cc 4a3bddd74f36 src/arch/x86/insts/microregop.cc 4a3bddd74f36 src/arch/x86/insts/static_inst.hh 4a3bddd74f36 src/arch/x86/interrupts.cc 4a3bddd74f36 src/arch/x86/isa/includes.isa 4a3bddd74f36 src/arch/x86/nativetrace.cc 4a3bddd74f36 src/arch/x86/pagetable_walker.cc 4a3bddd74f36 src/arch/x86/predecoder.hh 4a3bddd74f36 src/arch/x86/predecoder.cc 4a3bddd74f36 src/arch/x86/process.cc 4a3bddd74f36 src/arch/x86/stacktrace.hh 4a3bddd74f36 src/arch/x86/tlb.cc 4a3bddd74f36 src/base/debug.hh 4a3bddd74f36 src/base/debug.cc 4a3bddd74f36 src/base/loader/aout_object.cc 4a3bddd74f36 src/base/loader/ecoff_object.cc 4a3bddd74f36 src/base/loader/elf_object.cc 4a3bddd74f36 src/base/loader/raw_object.cc 4a3bddd74f36 src/base/mysql.cc 4a3bddd74f36 src/base/remote_gdb.cc 4a3bddd74f36 src/base/trace.hh 4a3bddd74f36 src/base/trace.cc 4a3bddd74f36 src/cpu/activity.cc 4a3bddd74f36 src/cpu/base.cc
Re: [m5-dev] src/base comments
I think we really need some better documentation on the files is src/base. They're supposed to be generic code that is used throughout M5, but I don't even know what some of it does. Minimally, we should have doxgyen comments on the files that describe what the code is trying to do, and preferably some information about how to actually use it in comments on the constructor and major functions. I've gone through all the code in that directory and come up with the list below of the person who wrote the code. It shouldn't take more than an hour (except for Nate), and think of it as a gift for all the M5 developers: Sounds like a great idea, but I honestly have more pressing code to commit that will take a lot of my time. I'm happy to review diffs, but for now, this is probably not going to get done any time soon. Also some of these really are not mine: I had nothing to do with these: predictor.hh res_list.hh I guess I can do this, but again, time is an issue. timebuf.hh (or try to get Kevin to do it) ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/slicc/symbols/StateMachine.py 998b217dcae7 src/mem/slicc/parser.py 998b217dcae7 src/mem/slicc/symbols/Func.py 998b217dcae7 src/mem/slicc/ast/StaticCastAST.py 998b217dcae7 src/mem/slicc/ast/TypeDeclAST.py 998b217dcae7 src/mem/slicc/ast/MethodCallExprAST.py 998b217dcae7 src/mem/slicc/ast/InPortDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncCallExprAST.py 998b217dcae7 src/mem/slicc/ast/FormalParamAST.py 998b217dcae7 src/mem/protocol/RubySlicc_Types.sm 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc 998b217dcae7 src/mem/ruby/system/CacheMemory.hh 998b217dcae7 src/mem/ruby/system/CacheMemory.cc 998b217dcae7 src/mem/ruby/system/TBETable.hh 998b217dcae7 src/mem/slicc/ast/ActionDeclAST.py 998b217dcae7 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory protocol. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Deadlock while running ruby_random_test.py
Hi Nilay, The following protocols (all of which are tested by the regression tester) should correctly work with the ruby random tester. MOESI_CMP_directory MOESI_hammer MOESI_token MI_example Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Tuesday, December 21, 2010 6:24 PM To: M5 Developer List Subject: Re: [m5-dev] Deadlock while running ruby_random_test.py Brad, which protocols work correctly with ruby random tester? On Tue, 21 Dec 2010, Beckmann, Brad wrote: Hi Nilay, If I'm correctly reproducing your problem, I believe I know what the issue is. However, before I try to fix it, I want to propose simply getting rid of the MESI_CMP_directory. The more and more I look at that protocol, the more problems I see. There are several design and logic issues in the protocol. Unless someone wants to volunteer to fix them, I say we get rid of it as well as all of the protocols not being tested by the regression tester. Now the particular problem that I see causing the deadlock is that that L2 cache is drop a PUTX request from the L1 because the L2 is in SS_MB state. Thus the L1 remains in M_I state for infinity which of course will eventually lead to a deadlock. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Tuesday, December 21, 2010 1:04 PM To: m5-dev@m5sim.org Subject: [m5-dev] Deadlock while running ruby_random_test.py I am running ALPHA_SE_MESI_CMP_directory with ruby_random_test.py. I supply the option -l as 2000. I have pasted the output below. This was generated using latest version of m5. Actually, while testing my own changes to SLICC and protocol files, I also observe the dead lock at the 301. So I ran the latest version and found even that gets stuck. Is this a known problem? Am I doing some thing wrong? Thanks Nilay ___ 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
Re: [m5-dev] Deadlock while running ruby_random_test.py
Yep that is the beauty of the random tester. It is much easier to fix problems when you can reproduce them in 3 M cycles vs. 200 B. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Sent: Tuesday, December 21, 2010 8:00 PM To: M5 Developer List Subject: Re: [m5-dev] Deadlock while running ruby_random_test.py It is kind of surprising that random tester can detect the bug with in 3,000,000 cycles while nothing happened on running ruby_fs.py for 200,000,000,000 cycles. On Tue, December 21, 2010 8:24 pm, Nilay Vaish wrote: Brad, which protocols work correctly with ruby random tester? On Tue, 21 Dec 2010, Beckmann, Brad wrote: Hi Nilay, If I'm correctly reproducing your problem, I believe I know what the issue is. However, before I try to fix it, I want to propose simply getting rid of the MESI_CMP_directory. The more and more I look at that protocol, the more problems I see. There are several design and logic issues in the protocol. Unless someone wants to volunteer to fix them, I say we get rid of it as well as all of the protocols not being tested by the regression tester. Now the particular problem that I see causing the deadlock is that that L2 cache is drop a PUTX request from the L1 because the L2 is in SS_MB state. Thus the L1 remains in M_I state for infinity which of course will eventually lead to a deadlock. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Tuesday, December 21, 2010 1:04 PM To: m5-dev@m5sim.org Subject: [m5-dev] Deadlock while running ruby_random_test.py I am running ALPHA_SE_MESI_CMP_directory with ruby_random_test.py. I supply the option -l as 2000. I have pasted the output below. This was generated using latest version of m5. Actually, while testing my own changes to SLICC and protocol files, I also observe the dead lock at the 301. So I ran the latest version and found even that gets stuck. Is this a known problem? Am I doing some thing wrong? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- Nilay ___ 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
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review570 --- Hi Nilay, Could you please include the changes to the MOESI_CMP_directory protocol in this patch? It is difficult to understand the ramifications of these changes without seeing their impact to the .sm files. Also this is a very tricky patch and the holiday break is approaching, so please be patient. I will try to get you my feedback as soon as I can. Brad - Brad On 2010-12-22 14:21:09, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2010-12-22 14:21:09) Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/slicc/symbols/StateMachine.py 998b217dcae7 src/mem/slicc/parser.py 998b217dcae7 src/mem/slicc/symbols/Func.py 998b217dcae7 src/mem/slicc/ast/StaticCastAST.py 998b217dcae7 src/mem/slicc/ast/TypeDeclAST.py 998b217dcae7 src/mem/slicc/ast/MethodCallExprAST.py 998b217dcae7 src/mem/slicc/ast/InPortDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncCallExprAST.py 998b217dcae7 src/mem/slicc/ast/FormalParamAST.py 998b217dcae7 src/mem/protocol/RubySlicc_Types.sm 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc 998b217dcae7 src/mem/ruby/system/CacheMemory.hh 998b217dcae7 src/mem/ruby/system/CacheMemory.cc 998b217dcae7 src/mem/ruby/system/TBETable.hh 998b217dcae7 src/mem/slicc/ast/ActionDeclAST.py 998b217dcae7 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory protocol. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: trace: reimplement the DTRACE function so it doesn't use a vector
On 2010-12-21 22:44:19, Steve Reinhardt wrote: The name trace flags doesn't bother me, but debug flags is OK too. I wouldn't want to be more generic than that though. Nathan Binkert wrote: I was thinking of adding a command line option for --debug-flags, but leaving the --trace-flags one there as well. Sound reasonable? Is there a real need for backward compatibility? Maybe we could have --trace-flags print a polite error message letting people know that the option has been renamed, so people's brains have time to retrain themselves, but if we really want to start using the new name then hanging on to the old option is only going to prolong the confusion IMO. Others may differ... - Steve --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/#review564 --- On 2010-12-21 08:36:19, Nathan Binkert wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/352/ --- (Updated 2010-12-21 08:36:19) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- trace: reimplement the DTRACE function so it doesn't use a vector One question I have about this stuff is if I should call everything trace, or debug? This diff is somewhat confused about that (some things are trace and some things are debug) and I expect to fix it. We always called this stuff trace flags in the past, but we I would like to start using these flags for other things. For example, turning on and off debugging breakpoints of different kinds. Execution tracing is a totally different mechanism but does use trace flags. My personal inclination is that trace flag is probably a bad name, but perhaps debug is a bad name too. Just call it flags? Or SimFlags? Diffs - src/SConscript 4a3bddd74f36 src/arch/alpha/interrupts.hh 4a3bddd74f36 src/arch/alpha/kernel_stats.cc 4a3bddd74f36 src/arch/alpha/linux/process.cc 4a3bddd74f36 src/arch/alpha/linux/system.cc 4a3bddd74f36 src/arch/alpha/process.cc 4a3bddd74f36 src/arch/alpha/remote_gdb.cc 4a3bddd74f36 src/arch/alpha/stacktrace.hh 4a3bddd74f36 src/arch/alpha/system.cc 4a3bddd74f36 src/arch/alpha/tlb.cc 4a3bddd74f36 src/arch/alpha/vtophys.cc 4a3bddd74f36 src/arch/arm/faults.cc 4a3bddd74f36 src/arch/arm/isa.hh 4a3bddd74f36 src/arch/arm/isa.cc 4a3bddd74f36 src/arch/arm/isa/includes.isa 4a3bddd74f36 src/arch/arm/nativetrace.cc 4a3bddd74f36 src/arch/arm/predecoder.cc 4a3bddd74f36 src/arch/arm/process.cc 4a3bddd74f36 src/arch/arm/remote_gdb.cc 4a3bddd74f36 src/arch/arm/stacktrace.hh 4a3bddd74f36 src/arch/arm/tlb.cc 4a3bddd74f36 src/arch/mips/faults.cc 4a3bddd74f36 src/arch/mips/isa.cc 4a3bddd74f36 src/arch/mips/isa/includes.isa 4a3bddd74f36 src/arch/mips/linux/process.cc 4a3bddd74f36 src/arch/mips/locked_mem.hh 4a3bddd74f36 src/arch/mips/process.cc 4a3bddd74f36 src/arch/mips/stacktrace.hh 4a3bddd74f36 src/arch/mips/tlb.cc 4a3bddd74f36 src/arch/power/process.cc 4a3bddd74f36 src/arch/power/stacktrace.hh 4a3bddd74f36 src/arch/power/tlb.cc 4a3bddd74f36 src/arch/sparc/interrupts.hh 4a3bddd74f36 src/arch/sparc/isa.cc 4a3bddd74f36 src/arch/sparc/isa/includes.isa 4a3bddd74f36 src/arch/sparc/process.cc 4a3bddd74f36 src/arch/sparc/remote_gdb.cc 4a3bddd74f36 src/arch/sparc/stacktrace.hh 4a3bddd74f36 src/arch/sparc/tlb.cc 4a3bddd74f36 src/arch/sparc/ua2005.cc 4a3bddd74f36 src/arch/sparc/vtophys.cc 4a3bddd74f36 src/arch/x86/faults.cc 4a3bddd74f36 src/arch/x86/insts/microregop.cc 4a3bddd74f36 src/arch/x86/insts/static_inst.hh 4a3bddd74f36 src/arch/x86/interrupts.cc 4a3bddd74f36 src/arch/x86/isa/includes.isa 4a3bddd74f36 src/arch/x86/nativetrace.cc 4a3bddd74f36 src/arch/x86/pagetable_walker.cc 4a3bddd74f36 src/arch/x86/predecoder.hh 4a3bddd74f36 src/arch/x86/predecoder.cc 4a3bddd74f36 src/arch/x86/process.cc 4a3bddd74f36 src/arch/x86/stacktrace.hh 4a3bddd74f36 src/arch/x86/tlb.cc 4a3bddd74f36 src/base/debug.hh 4a3bddd74f36 src/base/debug.cc 4a3bddd74f36 src/base/loader/aout_object.cc 4a3bddd74f36 src/base/loader/ecoff_object.cc 4a3bddd74f36 src/base/loader/elf_object.cc 4a3bddd74f36 src/base/loader/raw_object.cc 4a3bddd74f36 src/base/mysql.cc 4a3bddd74f36 src/base/remote_gdb.cc 4a3bddd74f36 src/base/trace.hh 4a3bddd74f36 src/base/trace.cc 4a3bddd74f36 src/cpu/activity.cc 4a3bddd74f36 src/cpu/base.cc 4a3bddd74f36 src/cpu/base_dyn_inst_impl.hh 4a3bddd74f36 src/cpu/exetrace.hh 4a3bddd74f36 src/cpu/exetrace.cc 4a3bddd74f36
[m5-dev] Review Request: Make commenting on close namespace brackets consistent.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Make commenting on close namespace brackets consistent. Diffs - src/dev/sinic.hh 42f343470ee3 src/dev/sinic.cc 42f343470ee3 src/dev/sinicreg.hh 42f343470ee3 src/dev/x86/cmos.hh 42f343470ee3 src/dev/x86/i8042.hh 42f343470ee3 src/dev/x86/i82094aa.hh 42f343470ee3 src/dev/x86/i8237.hh 42f343470ee3 src/dev/x86/i8254.hh 42f343470ee3 src/dev/x86/i8259.hh 42f343470ee3 src/dev/x86/intdev.hh 42f343470ee3 src/dev/x86/speaker.hh 42f343470ee3 src/kern/kernel_stats.hh 42f343470ee3 src/kern/kernel_stats.cc 42f343470ee3 src/mem/ruby/common/Address.hh 42f343470ee3 src/sim/core.hh 42f343470ee3 src/sim/core.cc 42f343470ee3 src/sim/insttracer.hh 42f343470ee3 src/sim/pseudo_inst.hh 42f343470ee3 src/sim/pseudo_inst.cc 42f343470ee3 src/sim/stat_control.hh 42f343470ee3 src/sim/stat_control.cc 42f343470ee3 src/base/trace.hh 42f343470ee3 src/base/trace.cc 42f343470ee3 src/base/varargs.hh 42f343470ee3 src/cpu/exetrace.hh 42f343470ee3 src/cpu/exetrace.cc 42f343470ee3 src/cpu/inorder/inorder_trace.hh 42f343470ee3 src/cpu/inorder/inorder_trace.cc 42f343470ee3 src/cpu/inteltrace.hh 42f343470ee3 src/cpu/inteltrace.cc 42f343470ee3 src/cpu/legiontrace.hh 42f343470ee3 src/cpu/legiontrace.cc 42f343470ee3 src/cpu/nativetrace.hh 42f343470ee3 src/cpu/nativetrace.cc 42f343470ee3 src/dev/copy_engine_defs.hh 42f343470ee3 src/dev/i8254xGBe_defs.hh 42f343470ee3 src/arch/power/insts/integer.hh 42f343470ee3 src/arch/power/insts/mem.hh 42f343470ee3 src/arch/power/insts/misc.hh 42f343470ee3 src/arch/power/insts/static_inst.hh 42f343470ee3 src/arch/power/isa.hh 42f343470ee3 src/arch/power/isa_traits.hh 42f343470ee3 src/arch/power/locked_mem.hh 42f343470ee3 src/arch/power/microcode_rom.hh 42f343470ee3 src/arch/power/miscregs.hh 42f343470ee3 src/arch/power/mmaped_ipr.hh 42f343470ee3 src/arch/power/pagetable.hh 42f343470ee3 src/arch/power/pagetable.cc 42f343470ee3 src/arch/power/predecoder.hh 42f343470ee3 src/arch/power/registers.hh 42f343470ee3 src/arch/power/remote_gdb.hh 42f343470ee3 src/arch/power/stacktrace.hh 42f343470ee3 src/arch/power/tlb.hh 42f343470ee3 src/arch/power/types.hh 42f343470ee3 src/arch/power/utility.hh 42f343470ee3 src/arch/power/utility.cc 42f343470ee3 src/arch/power/vtophys.hh 42f343470ee3 src/arch/sparc/faults.hh 42f343470ee3 src/arch/sparc/kernel_stats.hh 42f343470ee3 src/arch/sparc/nativetrace.hh 42f343470ee3 src/arch/sparc/nativetrace.cc 42f343470ee3 src/arch/sparc/tlb.cc 42f343470ee3 src/arch/sparc/vtophys.cc 42f343470ee3 src/arch/x86/cpuid.cc 42f343470ee3 src/arch/x86/nativetrace.hh 42f343470ee3 src/arch/x86/nativetrace.cc 42f343470ee3 src/arch/x86/registers.hh 42f343470ee3 src/arch/x86/tlb.cc 42f343470ee3 src/arch/x86/utility.cc 42f343470ee3 src/base/cprintf.hh 42f343470ee3 src/base/cprintf.cc 42f343470ee3 src/base/hashmap.hh 42f343470ee3 src/base/inet.hh 42f343470ee3 src/base/inet.cc 42f343470ee3 src/base/mysql.hh 42f343470ee3 src/base/mysql.cc 42f343470ee3 src/base/statistics.hh 42f343470ee3 src/base/statistics.cc 42f343470ee3 src/base/stats/info.hh 42f343470ee3 src/base/stats/mysql.hh 42f343470ee3 src/base/stats/mysql.cc 42f343470ee3 src/base/stats/mysql_run.hh 42f343470ee3 src/base/stats/output.hh 42f343470ee3 src/base/stats/output.cc 42f343470ee3 src/base/stats/text.hh 42f343470ee3 src/base/stats/text.cc 42f343470ee3 src/base/stats/types.hh 42f343470ee3 src/base/stats/visit.hh 42f343470ee3 src/base/stats/visit.cc 42f343470ee3 src/base/stl_helpers.hh 42f343470ee3 src/arch/arm/nativetrace.cc 42f343470ee3 src/arch/arm/tlb.hh 42f343470ee3 src/arch/mips/dsp.hh 42f343470ee3 src/arch/mips/faults.hh 42f343470ee3 src/arch/mips/isa_traits.hh 42f343470ee3 src/arch/mips/kernel_stats.hh 42f343470ee3 src/arch/mips/linux/threadinfo.hh 42f343470ee3 src/arch/power/faults.hh 42f343470ee3 src/arch/power/insts/branch.hh 42f343470ee3 src/arch/power/insts/condition.hh 42f343470ee3 src/arch/power/insts/floating.hh 42f343470ee3 src/arch/alpha/mt.hh 42f343470ee3 src/arch/alpha/pagetable.cc 42f343470ee3 src/arch/alpha/tlb.cc 42f343470ee3 src/arch/arm/faults.hh 42f343470ee3 src/arch/arm/isa_traits.hh 42f343470ee3 src/arch/arm/kernel_stats.hh 42f343470ee3 src/arch/arm/nativetrace.hh 42f343470ee3 Diff: http://reviews.m5sim.org/r/360/diff Testing --- still compiles Thanks, Steve ___ m5-dev mailing list m5-dev@m5sim.org
Re: [m5-dev] Review Request: debug: create a Debug namespace
On 2010-12-21 22:30:11, Steve Reinhardt wrote:
src/base/debug.hh, line 38
http://reviews.m5sim.org/r/351/diff/1/?file=5592#file5592line38
It looks like we're not completely consistent on this, but I'd put the
close brace in column 0, then put the comment after that, e.g.:
} // namespace Debug
I don't care much about C vs C++-style comments, but having the brace
in column 0 seems much more natural since that's where it would be if we
weren't commenting it.
Other than that nit (which applies several places), this looks good to
me.
Nathan Binkert wrote:
I've been doing it this way for years :) I think the reason that I
decided to do it this way is that we chose to *not* have namespaces change
the indention level. I honestly don't care, but there are a ton of examples
that look like this, so we should consciously decide on one and change them
everywhere and document it. (Since you brought it up, do you volunteer?
Offering code goes a hell of a long way in a coding debate :)
Ask and ye shall receive... sometimes, anyway. FYI, the '//' comments
outnumbered the '/*' comments something like 79 to 54, but there was surprising
variety in the details ('namespace Foo', 'end namespace Foo', 'Foo namespace').
But hey, stand back, I know regular expressions :-)
- Steve
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/351/#review563
---
On 2010-12-21 08:25:03, Nathan Binkert wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/351/
---
(Updated 2010-12-21 08:25:03)
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
Nathan Binkert.
Summary
---
debug: create a Debug namespace
Diffs
-
src/arch/alpha/ev5.cc 4a3bddd74f36
src/base/debug.hh 4a3bddd74f36
src/base/debug.cc 4a3bddd74f36
src/base/statistics.cc 4a3bddd74f36
src/cpu/pc_event.cc 4a3bddd74f36
src/dev/ns_gige.cc 4a3bddd74f36
src/dev/sinic.cc 4a3bddd74f36
src/sim/debug.cc 4a3bddd74f36
src/sim/pseudo_inst.cc 4a3bddd74f36
Diff: http://reviews.m5sim.org/r/351/diff
Testing
---
Thanks,
Nathan
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
On 2010-12-22 14:35:28, Brad Beckmann wrote: Hi Nilay, Could you please include the changes to the MOESI_CMP_directory protocol in this patch? It is difficult to understand the ramifications of these changes without seeing their impact to the .sm files. Also this is a very tricky patch and the holiday break is approaching, so please be patient. I will try to get you my feedback as soon as I can. Brad I am trying to add the MOESI_CMP_directory protocol patch separately. But apparently review board is not able to apply that patch cleanly. Take your time to review all the changes. -- Nilay - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/#review570 --- On 2010-12-22 14:21:09, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/358/ --- (Updated 2010-12-22 14:21:09) Review request for Default. Summary --- The purpose of this patch is to change the way CacheMemory interfaces with coherence protocols. Currently, whenever a cache controller (defined in the protocol under consideration) needs to carry out any operation on a cache block, it looks up the tag hash map and figures out whether or not the block exists in the cache. In case it does exist, the operation is carried out (which requires another lookup). Over a single clock cycle, multiple such lookups take place as observed through profiling of different protocols. It was seen that the tag lookup takes anything from 10% to 20% of the simulation time. In order to reduce this time, this patch is being posted. The CacheMemory class now will have a function that will return pointer to a cache block entry, instead of a reference (though the function that returns the reference has been retained currently). Functions have been introduced for setting/unsetting a pointer and check its pointer. Similar changes have been carried out for Transaction Buffer entries as well. Note that changes are required to both SLICC and the protocol files. This patch carries out changes to SLICC and committing this patch alone, I believe, will ___break___ all the protocols. I am working on patching the protocols as well. This patch is being put to get feed back from other developers. Diffs - src/mem/slicc/symbols/StateMachine.py 998b217dcae7 src/mem/slicc/parser.py 998b217dcae7 src/mem/slicc/symbols/Func.py 998b217dcae7 src/mem/slicc/ast/StaticCastAST.py 998b217dcae7 src/mem/slicc/ast/TypeDeclAST.py 998b217dcae7 src/mem/slicc/ast/MethodCallExprAST.py 998b217dcae7 src/mem/slicc/ast/InPortDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncDeclAST.py 998b217dcae7 src/mem/slicc/ast/FuncCallExprAST.py 998b217dcae7 src/mem/slicc/ast/FormalParamAST.py 998b217dcae7 src/mem/protocol/RubySlicc_Types.sm 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh 998b217dcae7 src/mem/ruby/slicc_interface/AbstractCacheEntry.cc 998b217dcae7 src/mem/ruby/system/CacheMemory.hh 998b217dcae7 src/mem/ruby/system/CacheMemory.cc 998b217dcae7 src/mem/ruby/system/TBETable.hh 998b217dcae7 src/mem/slicc/ast/ActionDeclAST.py 998b217dcae7 Diff: http://reviews.m5sim.org/r/358/diff Testing --- I have tested these changes using the MOESI_CMP_directory protocol. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Make commenting on close namespace brackets consistent.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/#review574 --- Ship it! I only looked at a few. I hope that you don't expect anyone to read them all. Anyway, did you have any worthwhile regexes to put in the commit message? - Nathan On 2010-12-22 17:39:40, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/360/ --- (Updated 2010-12-22 17:39:40) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Make commenting on close namespace brackets consistent. Diffs - src/dev/sinic.hh 42f343470ee3 src/dev/sinic.cc 42f343470ee3 src/dev/sinicreg.hh 42f343470ee3 src/dev/x86/cmos.hh 42f343470ee3 src/dev/x86/i8042.hh 42f343470ee3 src/dev/x86/i82094aa.hh 42f343470ee3 src/dev/x86/i8237.hh 42f343470ee3 src/dev/x86/i8254.hh 42f343470ee3 src/dev/x86/i8259.hh 42f343470ee3 src/dev/x86/intdev.hh 42f343470ee3 src/dev/x86/speaker.hh 42f343470ee3 src/kern/kernel_stats.hh 42f343470ee3 src/kern/kernel_stats.cc 42f343470ee3 src/mem/ruby/common/Address.hh 42f343470ee3 src/sim/core.hh 42f343470ee3 src/sim/core.cc 42f343470ee3 src/sim/insttracer.hh 42f343470ee3 src/sim/pseudo_inst.hh 42f343470ee3 src/sim/pseudo_inst.cc 42f343470ee3 src/sim/stat_control.hh 42f343470ee3 src/sim/stat_control.cc 42f343470ee3 src/base/trace.hh 42f343470ee3 src/base/trace.cc 42f343470ee3 src/base/varargs.hh 42f343470ee3 src/cpu/exetrace.hh 42f343470ee3 src/cpu/exetrace.cc 42f343470ee3 src/cpu/inorder/inorder_trace.hh 42f343470ee3 src/cpu/inorder/inorder_trace.cc 42f343470ee3 src/cpu/inteltrace.hh 42f343470ee3 src/cpu/inteltrace.cc 42f343470ee3 src/cpu/legiontrace.hh 42f343470ee3 src/cpu/legiontrace.cc 42f343470ee3 src/cpu/nativetrace.hh 42f343470ee3 src/cpu/nativetrace.cc 42f343470ee3 src/dev/copy_engine_defs.hh 42f343470ee3 src/dev/i8254xGBe_defs.hh 42f343470ee3 src/arch/power/insts/integer.hh 42f343470ee3 src/arch/power/insts/mem.hh 42f343470ee3 src/arch/power/insts/misc.hh 42f343470ee3 src/arch/power/insts/static_inst.hh 42f343470ee3 src/arch/power/isa.hh 42f343470ee3 src/arch/power/isa_traits.hh 42f343470ee3 src/arch/power/locked_mem.hh 42f343470ee3 src/arch/power/microcode_rom.hh 42f343470ee3 src/arch/power/miscregs.hh 42f343470ee3 src/arch/power/mmaped_ipr.hh 42f343470ee3 src/arch/power/pagetable.hh 42f343470ee3 src/arch/power/pagetable.cc 42f343470ee3 src/arch/power/predecoder.hh 42f343470ee3 src/arch/power/registers.hh 42f343470ee3 src/arch/power/remote_gdb.hh 42f343470ee3 src/arch/power/stacktrace.hh 42f343470ee3 src/arch/power/tlb.hh 42f343470ee3 src/arch/power/types.hh 42f343470ee3 src/arch/power/utility.hh 42f343470ee3 src/arch/power/utility.cc 42f343470ee3 src/arch/power/vtophys.hh 42f343470ee3 src/arch/sparc/faults.hh 42f343470ee3 src/arch/sparc/kernel_stats.hh 42f343470ee3 src/arch/sparc/nativetrace.hh 42f343470ee3 src/arch/sparc/nativetrace.cc 42f343470ee3 src/arch/sparc/tlb.cc 42f343470ee3 src/arch/sparc/vtophys.cc 42f343470ee3 src/arch/x86/cpuid.cc 42f343470ee3 src/arch/x86/nativetrace.hh 42f343470ee3 src/arch/x86/nativetrace.cc 42f343470ee3 src/arch/x86/registers.hh 42f343470ee3 src/arch/x86/tlb.cc 42f343470ee3 src/arch/x86/utility.cc 42f343470ee3 src/base/cprintf.hh 42f343470ee3 src/base/cprintf.cc 42f343470ee3 src/base/hashmap.hh 42f343470ee3 src/base/inet.hh 42f343470ee3 src/base/inet.cc 42f343470ee3 src/base/mysql.hh 42f343470ee3 src/base/mysql.cc 42f343470ee3 src/base/statistics.hh 42f343470ee3 src/base/statistics.cc 42f343470ee3 src/base/stats/info.hh 42f343470ee3 src/base/stats/mysql.hh 42f343470ee3 src/base/stats/mysql.cc 42f343470ee3 src/base/stats/mysql_run.hh 42f343470ee3 src/base/stats/output.hh 42f343470ee3 src/base/stats/output.cc 42f343470ee3 src/base/stats/text.hh 42f343470ee3 src/base/stats/text.cc 42f343470ee3 src/base/stats/types.hh 42f343470ee3 src/base/stats/visit.hh 42f343470ee3 src/base/stats/visit.cc 42f343470ee3 src/base/stl_helpers.hh 42f343470ee3 src/arch/arm/nativetrace.cc 42f343470ee3 src/arch/arm/tlb.hh 42f343470ee3 src/arch/mips/dsp.hh 42f343470ee3 src/arch/mips/faults.hh 42f343470ee3 src/arch/mips/isa_traits.hh 42f343470ee3 src/arch/mips/kernel_stats.hh 42f343470ee3 src/arch/mips/linux/threadinfo.hh 42f343470ee3 src/arch/power/faults.hh 42f343470ee3 src/arch/power/insts/branch.hh 42f343470ee3
Re: [m5-dev] Error in uploading diff
I don't have time to look at it right now, but I've attached the directory that the error message is referring to. On Wed, Dec 22, 2010 at 6:22 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Can some one try applying the attached diff? It touches only src/mem/protocol/MOESI_CMP_directory-* files. Review Board is failing in applying this diff. I tried and it works correctly. This is the output from Review Board -- The patch to 'src/mem/protocol/MOESI_CMP_directory-L1cache.sm' didn't apply cleanly. The temporary files have been left in '/tmp/reviewboard.3s7DQ8' for debugging purposes. `patch` returned: patching file /tmp/reviewboard.3s7DQ8/tmpAp0ogH Hunk #1 succeeded at 6 with fuzz 2 (offset -130 lines). Hunk #2 FAILED at 150. Hunk #3 FAILED at 184. Hunk #4 FAILED at 272. Hunk #5 FAILED at 289. Hunk #6 FAILED at 306. Hunk #7 FAILED at 335. Hunk #8 FAILED at 353. Hunk #9 FAILED at 373. Hunk #10 FAILED at 380. Hunk #11 FAILED at 393. Hunk #12 FAILED at 425. Hunk #13 FAILED at 440. Hunk #14 FAILED at 479. Hunk #15 FAILED at 493. Hunk #16 FAILED at 511. Hunk #17 FAILED at 529. Hunk #18 FAILED at 543. Hunk #19 FAILED at 597. Hunk #20 FAILED at 604. Hunk #21 FAILED at 640. Hunk #22 FAILED at 655. Hunk #23 FAILED at 676. Hunk #24 FAILED at 690. Hunk #25 FAILED at 708. Hunk #26 FAILED at 721. Hunk #27 FAILED at 739. Hunk #28 FAILED at 768. Hunk #29 FAILED at 780. Hunk #30 FAILED at 1180. 29 out of 30 hunks FAILED -- saving rejects to file /tmp/reviewboard.3s7DQ8/tmpAp0ogH-new.rej Do you think some thing is wrong with the diff? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev reviewboard.3s7DQ8.tar.gz Description: GNU Zip compressed data ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Updating MOESI CMP Directory protocol as per the new interface
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/359/ --- Review request for Default. Summary --- This is a request for reviewing the proposed changes to the MOESI CMP directory cache coherence protocol to make it conform with the new cache memory interface and changes to SLICC. Diffs - src/mem/protocol/MOESI_CMP_directory-dir.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-dma.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-L2cache.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-L1cache.sm UNKNOWN Diff: http://reviews.m5sim.org/r/359/diff Testing --- These changes have been tested using the Ruby random tester. The tester was used with -l = 1048576 and -n = 2. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: This patch removes the WARN_* and ERROR_* from ...
changeset f249937228b5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f249937228b5
description:
This patch removes the WARN_* and ERROR_* from
src/mem/ruby/common/Debug.hh file. These statements have been replaced with
warn(), panic() and fatal() defined in src/base/misc.hh
diffstat:
src/cpu/testers/rubytest/Check.cc| 25 +--
src/cpu/testers/rubytest/CheckTable.cc | 2 +-
src/cpu/testers/rubytest/RubyTester.cc | 10 +-
src/mem/protocol/RubySlicc_Util.sm | 1 -
src/mem/ruby/buffers/MessageBuffer.cc| 20 +--
src/mem/ruby/common/Debug.hh | 65
--
src/mem/ruby/common/NetDest.cc | 4 +-
src/mem/ruby/common/Set.cc | 7 +-
src/mem/ruby/network/Network.cc | 6 +-
src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc| 6 +-
src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc | 3 +-
src/mem/ruby/network/garnet/fixed-pipeline/RoutingUnit_d.cc | 2 +-
src/mem/ruby/network/garnet/fixed-pipeline/SWallocator_d.cc | 3 +-
src/mem/ruby/network/garnet/fixed-pipeline/VCallocator_d.cc | 3 +-
src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc | 6 +-
src/mem/ruby/slicc_interface/RubySlicc_ComponentMapping.hh | 3 +-
src/mem/ruby/slicc_interface/RubySlicc_Util.hh | 6 -
src/mem/ruby/storebuffer/storebuffer.cc | 28 +--
src/mem/ruby/system/CacheMemory.cc | 2 +-
src/mem/ruby/system/PerfectCacheMemory.hh| 4 +-
src/mem/ruby/system/Sequencer.cc | 29 ++--
src/mem/ruby/tester/DeterministicDriver.cc | 3 +-
src/mem/ruby/tester/RaceyPseudoThread.cc | 10 +-
src/mem/ruby/tester/test_framework.cc| 3 +-
src/mem/slicc/symbols/StateMachine.py| 10 +-
src/mem/slicc/symbols/Type.py| 19 +-
26 files changed, 87 insertions(+), 193 deletions(-)
diffs (truncated from 775 to 300 lines):
diff -r 42f343470ee3 -r f249937228b5 src/cpu/testers/rubytest/Check.cc
--- a/src/cpu/testers/rubytest/Check.cc Tue Dec 21 22:57:29 2010 -0800
+++ b/src/cpu/testers/rubytest/Check.cc Wed Dec 22 23:15:24 2010 -0600
@@ -270,15 +270,13 @@
// Perform load/check
for (int byte_number=0; byte_numberCHECK_SIZE; byte_number++) {
if (uint8(m_value + byte_number) != data-getByte(byte_number)) {
-WARN_EXPR(proc);
-WARN_EXPR(address);
-WARN_EXPR(data);
-WARN_EXPR(byte_number);
-WARN_EXPR((int)m_value + byte_number);
-WARN_EXPR((int)data-getByte(byte_number));
-WARN_EXPR(*this);
-WARN_EXPR(g_eventQueue_ptr-getTime());
-ERROR_MSG(Action/check failure);
+panic(Action/check failure: proc: %d address: %s data: %s
+ byte_number: %d m_value+byte_number: %d byte: %d %s
+ Time: %d\n,
+ proc, address, data, byte_number,
+ (int)m_value + byte_number,
+ (int)data-getByte(byte_number), *this,
+ g_eventQueue_ptr-getTime());
}
}
DPRINTF(RubyTest, Action/check success\n);
@@ -291,12 +289,9 @@
pickValue();
} else {
-WARN_EXPR(*this);
-WARN_EXPR(proc);
-WARN_EXPR(data);
-WARN_EXPR(m_status);
-WARN_EXPR(g_eventQueue_ptr-getTime());
-ERROR_MSG(Unexpected TesterStatus);
+panic(Unexpected TesterStatus: %s proc: %d data: %s m_status: %s
+ time: %d\n,
+ *this, proc, data, m_status, g_eventQueue_ptr-getTime());
}
DPRINTF(RubyTest, proc: %d, Address: 0x%x\n, proc,
diff -r 42f343470ee3 -r f249937228b5 src/cpu/testers/rubytest/CheckTable.cc
--- a/src/cpu/testers/rubytest/CheckTable.ccTue Dec 21 22:57:29 2010 -0800
+++ b/src/cpu/testers/rubytest/CheckTable.ccWed Dec 22 23:15:24 2010 -0600
@@ -81,7 +81,7 @@
{
if (floorLog2(CHECK_SIZE) != 0) {
if (address.bitSelect(0, CHECK_SIZE_BITS - 1) != 0) {
-ERROR_MSG(Check not aligned);
+panic(Check not aligned);
}
}
diff -r 42f343470ee3 -r f249937228b5 src/cpu/testers/rubytest/RubyTester.cc
--- a/src/cpu/testers/rubytest/RubyTester.ccTue Dec 21 22:57:29 2010 -0800
+++ b/src/cpu/testers/rubytest/RubyTester.ccWed Dec 22 23:15:24 2010 -0600
@@ -27,6 +27,7 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+#include base/misc.hh
Re: [m5-dev] Error in uploading diff
Apparently Review Board requires git-styled diffs. On Wed, December 22, 2010 8:34 pm, nathan binkert wrote: I don't have time to look at it right now, but I've attached the directory that the error message is referring to. On Wed, Dec 22, 2010 at 6:22 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Can some one try applying the attached diff? It touches only src/mem/protocol/MOESI_CMP_directory-* files. Review Board is failing in applying this diff. I tried and it works correctly. This is the output from Review Board -- The patch to 'src/mem/protocol/MOESI_CMP_directory-L1cache.sm' didn't apply cleanly. The temporary files have been left in '/tmp/reviewboard.3s7DQ8' for debugging purposes. `patch` returned: patching file /tmp/reviewboard.3s7DQ8/tmpAp0ogH Hunk #1 succeeded at 6 with fuzz 2 (offset -130 lines). Hunk #2 FAILED at 150. Hunk #3 FAILED at 184. Hunk #4 FAILED at 272. Hunk #5 FAILED at 289. Hunk #6 FAILED at 306. Hunk #7 FAILED at 335. Hunk #8 FAILED at 353. Hunk #9 FAILED at 373. Hunk #10 FAILED at 380. Hunk #11 FAILED at 393. Hunk #12 FAILED at 425. Hunk #13 FAILED at 440. Hunk #14 FAILED at 479. Hunk #15 FAILED at 493. Hunk #16 FAILED at 511. Hunk #17 FAILED at 529. Hunk #18 FAILED at 543. Hunk #19 FAILED at 597. Hunk #20 FAILED at 604. Hunk #21 FAILED at 640. Hunk #22 FAILED at 655. Hunk #23 FAILED at 676. Hunk #24 FAILED at 690. Hunk #25 FAILED at 708. Hunk #26 FAILED at 721. Hunk #27 FAILED at 739. Hunk #28 FAILED at 768. Hunk #29 FAILED at 780. Hunk #30 FAILED at 1180. 29 out of 30 hunks FAILED -- saving rejects to file /tmp/reviewboard.3s7DQ8/tmpAp0ogH-new.rej Do you think some thing is wrong with the diff? Thanks Nilay ___ 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 -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
