[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* 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/60.rubytest/alpha/linux/rubytest-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_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_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_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/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory 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/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory 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/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer 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/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing 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-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 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/linux/simple-timing-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/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual 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/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest 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-ruby 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-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby 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. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I tried M5_DUMMY_RETURN and it it not working. I checked its definition.
It would evaluate to nothing, in which case I do not see why it should
help in avoiding the warning. I tried putting a return statement before
panic();
return panic(not implemented);
This works with GCC 4.2.2.
I checked whether GCC has some recorded bug reports for this. I found the
following two -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42674
I tried the provided codes. For the first one, 4.2.2 raises a warning but
4.4.0 does not. For the second one, 4.4.0 raises a warning but 4.2.2 does
not.
--
Nilay
On Thu, 23 Dec 2010, Ali Saidi wrote:
A better solution would be to put M5_DUMMY_RETURN there. I know there'd
were some issues with some versions of gcc not respecting the attribute
no return. This might be the case.
Ali
Sent from my ARM powered device
On Dec 23, 2010, at 1:10 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
I am able to reproduce the warning. But I have to compile the files on
my own (as in, write the compilation command on the command line) in
order to reproduce the warning.
This is the proposed patch.
--
Nilay
diff --git a/src/mem/ruby/system/PerfectCacheMemory.hh
b/src/mem/ruby/system/PerfectCacheMemory.hh
--- a/src/mem/ruby/system/PerfectCacheMemory.hh
+++ b/src/mem/ruby/system/PerfectCacheMemory.hh
@@ -124,6 +124,7 @@
bool block_stc, ENTRY* entry)
{
panic(not implemented);
+return true;
}
// tests to see if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemoryENTRY::cacheProbe(const Address newAddress) const
{
panic(cacheProbe called in perfect cache);
+return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I do not have GCC 4.2.4, but with GCC 4.2.2 I do not see those warnings.
On Thu, 23 Dec 2010, Steve Reinhardt wrote:
It could be an issue with gcc 4.2.4 not properly handling the no return
attribute in some cases... that being a bug that's fixed in 4.4 would
explain why it works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, Nilay Vaish ni...@cs.wisc.edu wrote:
Steve, you had commented that panic() and fatal() are marked as no
return. Then, why should these warnings appear? And why would the compiler
be fine with ERROR_MSG?
--
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
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Updates MI cache coherence protocol
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/335/ --- Review request for Default. Summary --- This is a review request for the patch that updates the MI cache coherence protocol to conform with the new interfaces of CacheMemory and TBETable classes, and the changes in SLICC. Diffs - src/mem/protocol/MI_example-cache.sm UNKNOWN src/mem/protocol/MI_example-dir.sm UNKNOWN Diff: http://reviews.m5sim.org/r/335/diff Testing --- Tested using ruby_random_tester.py with l = 10,000,000 and n = 2. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [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/ --- (Updated 2010-12-24 09:02:20.653744) Review request for Default. Changes --- is_valid_cache_entry() and is_valid_tbe() have been removed. These have been replaced with a call to is_valid_ptr(ptr variable). 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 (updated) - src/mem/protocol/MOESI_CMP_directory-L1cache.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-L2cache.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-dir.sm UNKNOWN src/mem/protocol/MOESI_CMP_directory-dma.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
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/ --- (Updated 2010-12-24 09:04:02.816498) Review request for Default. Changes --- The functions is_valid_cache_entry() and is_valid_tbe() have been removed from the Controller class. Instead, these have been replaced with a unified call to is_valid_ptr(ptr variable). This new call is handled in the same fashion as check_allocate(). Functions changePermission() and getPermission() have been removed from the CacheMemory class. 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 (updated) - src/mem/protocol/RubySlicc_Types.sm UNKNOWN src/mem/ruby/slicc_interface/AbstractCacheEntry.hh UNKNOWN src/mem/ruby/slicc_interface/AbstractCacheEntry.cc UNKNOWN src/mem/ruby/system/CacheMemory.hh UNKNOWN src/mem/ruby/system/CacheMemory.cc UNKNOWN src/mem/ruby/system/TBETable.hh UNKNOWN src/mem/slicc/ast/ActionDeclAST.py UNKNOWN src/mem/slicc/ast/FormalParamAST.py UNKNOWN src/mem/slicc/ast/FuncCallExprAST.py UNKNOWN src/mem/slicc/ast/FuncDeclAST.py UNKNOWN src/mem/slicc/ast/InPortDeclAST.py UNKNOWN src/mem/slicc/ast/IsValidPtrExprAST.py PRE-CREATION src/mem/slicc/ast/MethodCallExprAST.py UNKNOWN src/mem/slicc/ast/StaticCastAST.py UNKNOWN src/mem/slicc/ast/TypeDeclAST.py UNKNOWN src/mem/slicc/ast/__init__.py UNKNOWN src/mem/slicc/parser.py UNKNOWN src/mem/slicc/symbols/StateMachine.py UNKNOWN Diff: http://reviews.m5sim.org/r/358/diff Testing (updated) --- I have tested these changes using the MOESI_CMP_directory and MI protocols. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] does drain need to be so complicated?
Long story, but CountedDrainEvent is bugging me (again)... it's not an event (it never gets scheduled; it's just a callback) and it derives unnecessarily from SimLoopExitEvent (it just uses the inherited cause and code fields to set the cause and code fields of a new SimLoopExitEvent it creates when it's really ready to exit). The resulting code is very confusing since it's not what it appears to be. One solution would be to make it a Callback object instead of an Event; this would at least make the code match the usage and purpose. However, that's not totally trivial, since the current event is exposed through swig to python so that the count value can be set from the python code. The result is that that simple change requires more swig and python tweaking than you might expect. It's not that much :) I'm wondering why we need to dynamically allocate this object at all... the only benefit I see is that in theory, we could have multiple disjoint parts of the system draining concurrently but with independent completion detection. In reality, I don't see how we would really do that, unless we had multiple python threads calling the python drain() function concurrently, which doesn't seem likely to happen in our lifetimes. Is anyone opposed to just using a global variable for the drain counter, and a global function to decrement it and exit the sim loop when it hits zero? I don't think a global variable will work because if you have two systems, they may not drain at the same time. I think that a drain count on the system object could work fine though. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] src/base comments
I looked a little more at the base dir, and there are a bunch more files are also unused (at least to the extent that I compiled everything successfully after I removed them). R src/base/compression/base.hh R src/base/compression/lzss_compression.cc R src/base/compression/lzss_compression.hh R src/base/compression/null_compression.hh The last remnant's of Erik's cache compression work... I expect that even if someone revisits that, they may want to use a different interface or something, so I'm fine with whacking this. Thoughts? Fine with me. R src/base/crc.cc R src/base/crc.hh Nate? I wonder why those were there. The history didn't help. Did it have to do with checksum offload or something? The tap device perhaps? Anyway, we can always resurrect it. R src/base/fifo_buffer.cc R src/base/fifo_buffer.hh R src/base/hybrid_pred.cc R src/base/hybrid_pred.hh R src/base/predictor.hh R src/base/res_list.hh R src/base/sat_counter.cc R src/base/sat_counter.hh I think these are all classes that Steve Raasch wrote for the old SS-based out-of-order model that are no longer used. I think we should definitely get rid of them. There are two files (sched_list.hh and timebuf.hh) that are used by some of the CPU models... these seem rather specialized for the base dir, and arguably could go into sim or even cpu. I'd say whack the old SS stuff and move the other two. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: PerfectCacheMemory: Add return statements to tw...
I am in complete agreement with you. But I do not want to keep the repository in a broken state. Ok. I like that attitude. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
