[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* 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-atomic-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/tru64/simple-timing-ruby 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/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 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-atomic-ruby 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-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-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/linux/simple-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing 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/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/ARM_SE/tests/fast/quick/00.hello/arm/linux/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-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/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-ruby passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp 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-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp-ruby passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp 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/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/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. See /z/m5/regression/regress-2009-07-30-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] MIPS_SE compile error
Korey, can you please comment on this? I'd like to commit a fix since
I'm running a compiler that fails on this as well.
Nate
On Wed, Jul 29, 2009 at 2:48 PM, Vince Weavervi...@csl.cornell.edu wrote:
Hello
not sure if this is the proper place to send packages, but here it goes
currently building for MIPS_SE fails. It looks like a = instead of a ==
error, but the code is pretty dense so I can't tell if it's trying to be
overly clever.
patch attached below.
Vince
diff -r b35ef789e6f6 src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/mips/mt.hh Wed Jul 29 17:42:04 2009 -0400
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND + Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
- if (tidTCBind.curVPE = tcBind.curVPE) {
+ if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
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] MIPS_SE compile error
This is actually my fault, I think. I changed around the code to use
BitUnions and I must have accidentally deleted an = here. I'm pretty
confident it's correct, but if you want to be sure you could look at
the diff of that change and see what the logic used to be. I'm a
little surprised that it failed to build for you since it seemed to
work fine as far as the regressions. Are you using a very new or old
compiler?
Gabe
Quoting nathan binkert n...@binkert.org:
Korey, can you please comment on this? I'd like to commit a fix since
I'm running a compiler that fails on this as well.
Nate
On Wed, Jul 29, 2009 at 2:48 PM, Vince Weavervi...@csl.cornell.edu wrote:
Hello
not sure if this is the proper place to send packages, but here it goes
currently building for MIPS_SE fails. It looks like a = instead of a ==
error, but the code is pretty dense so I can't tell if it's trying to be
overly clever.
patch attached below.
Vince
diff -r b35ef789e6f6 src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/mips/mt.hh Wed Jul 29 17:42:04 2009 -0400
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND + Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
- if (tidTCBind.curVPE = tcBind.curVPE) {
+ if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
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
Re: [m5-dev] MIPS_SE compile error
Confident that this fix is correct, that is. I just checked the diff
of the older change and I did accidentally nuke an =. If you're in a
hurry please go ahead and commit this fix.
Gabe
Quoting Gabriel Michael Black gbl...@eecs.umich.edu:
This is actually my fault, I think. I changed around the code to use
BitUnions and I must have accidentally deleted an = here. I'm pretty
confident it's correct, but if you want to be sure you could look at
the diff of that change and see what the logic used to be. I'm a
little surprised that it failed to build for you since it seemed to
work fine as far as the regressions. Are you using a very new or old
compiler?
Gabe
Quoting nathan binkert n...@binkert.org:
Korey, can you please comment on this? I'd like to commit a fix since
I'm running a compiler that fails on this as well.
Nate
On Wed, Jul 29, 2009 at 2:48 PM, Vince Weavervi...@csl.cornell.edu wrote:
Hello
not sure if this is the proper place to send packages, but here it goes
currently building for MIPS_SE fails. It looks like a = instead of a ==
error, but the code is pretty dense so I can't tell if it's trying to be
overly clever.
patch attached below.
Vince
diff -r b35ef789e6f6 src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 00:35:49 2009 -0700
+++ b/src/arch/mips/mt.hh Wed Jul 29 17:42:04 2009 -0400
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND +
Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
- if (tidTCBind.curVPE = tcBind.curVPE) {
+ if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
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 mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: compile: fix accidental conversion of == into =
changeset 58e3056d918e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=58e3056d918e
description:
compile: fix accidental conversion of == into =
diffstat:
1 file changed, 1 insertion(+), 1 deletion(-)
src/arch/mips/mt.hh |2 +-
diffs (12 lines):
diff -r 727622fa50e5 -r 58e3056d918e src/arch/mips/mt.hh
--- a/src/arch/mips/mt.hh Wed Jul 29 22:24:00 2009 -0700
+++ b/src/arch/mips/mt.hh Thu Jul 30 17:42:57 2009 -0700
@@ -118,7 +118,7 @@
tc-readRegOtherThread(MISCREG_TC_BIND + Ctrl_Base_DepTag, tid);
TCBindReg tcBind = tc-readMiscRegNoEffect(MISCREG_TC_BIND);
-if (tidTCBind.curVPE = tcBind.curVPE) {
+if (tidTCBind.curVPE == tcBind.curVPE) {
TCStatusReg tidTCStatus =
tc-readRegOtherThread(MISCREG_TC_STATUS +
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] GEM5 Issues
Hi All, Tushar and I have noticed a few issues with GEM5 and we were wondering if anyone had plans to fix them. If not, we'll go ahead and check in fixes to the global repository. I just want to make sure we're not stepping on anyone's toes. - Fix SLICC so that protocol generated files are created in separate protocol specific folders. Currently they are created in the same mem/protocol folder overwriting older files (eg. build/ALPHA_SE/mem/protocol//ControllerFactory.cc). - Fully integrate SLICC parsing errors into scons. Right now the error messages don't give any useful info. Should we hold off on fixing this until SLICCer is added to GEM5? - Support broadcast protocols with NetDest ruby functions. I notices that one of Derek's recent checkins removed all the NetDest functions in RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol specific, and needed to go. However there were a few general ones that are needed by any broadcast based protocol. Are there plans to add these back into the tree? - I appreciate that a lot of the controller assumptions on the ruby side have been removed. However, it appears that Ruby now assumes a DMA controller is present. Is there plans to clean this up. Again, we're happy to fix this stuff up ourselves. I just want to be sure there aren't plans already in progress. Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] GEM5 Issues
I have no plans to fix any of this, but please do not just check in fixes without sending out patches for review.I'm particularly interested in the first two. For the generated protocol code, are you trying to simultaneously compile multiple protocols into the same binary or just trying to make it so you don't have to recompile if you switch between the two. I don't know if you can do the latter without doing the former because of how scons does dependencies. I can say that I do know how to do the former. For the error messages, I see no reason not to fix this now. Nate Tushar and I have noticed a few issues with GEM5 and we were wondering if anyone had plans to fix them. If not, we'll go ahead and check in fixes to the global repository. I just want to make sure we're not stepping on anyone's toes. - Fix SLICC so that protocol generated files are created in separate protocol specific folders. Currently they are created in the same mem/protocol folder overwriting older files (eg. build/ALPHA_SE/mem/protocol//ControllerFactory.cc). - Fully integrate SLICC parsing errors into scons. Right now the error messages don't give any useful info. Should we hold off on fixing this until SLICCer is added to GEM5? - Support broadcast protocols with NetDest ruby functions. I notices that one of Derek's recent checkins removed all the NetDest functions in RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol specific, and needed to go. However there were a few general ones that are needed by any broadcast based protocol. Are there plans to add these back into the tree? - I appreciate that a lot of the controller assumptions on the ruby side have been removed. However, it appears that Ruby now assumes a DMA controller is present. Is there plans to clean this up. Again, we're happy to fix this stuff up ourselves. I just want to be sure there aren't plans already in progress. Thanks, Brad ___ 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] Fwd: GEM5 Issues
-- Forwarded message -- From: Derek Hower derek.ho...@gmail.com To: M5 Developer List m5-dev@m5sim.org Date: Thu, 30 Jul 2009 23:24:08 -0500 Subject: Re: [m5-dev] GEM5 Issues On Thu, Jul 30, 2009 at 7:46 PM, Beckmann, Bradbrad.beckm...@amd.com wrote: Hi All, Tushar and I have noticed a few issues with GEM5 and we were wondering if anyone had plans to fix them. If not, we'll go ahead and check in fixes to the global repository. I just want to make sure we're not stepping on anyone's toes. Glad to get some help!! - Fix SLICC so that protocol generated files are created in separate protocol specific folders. Currently they are created in the same mem/protocol folder overwriting older files (eg. build/ALPHA_SE/mem/protocol//ControllerFactory.cc). Go ahead with this one. - Fully integrate SLICC parsing errors into scons. Right now the error messages don't give any useful info. Should we hold off on fixing this until SLICCer is added to GEM5? I wouldn't hold off. SLICCer is still indefinitely postponed, at least on my end. I don't expect to work on it until November-ish. Even after SLICCer is around, I think it would be wise to maintain SLICC support for a while so this would be a good fix. - Support broadcast protocols with NetDest ruby functions. I notices that one of Derek's recent checkins removed all the NetDest functions in RubySlicc_ComponentMapping.hh. Most of them were lot old, protocol specific, and needed to go. However there were a few general ones that are needed by any broadcast based protocol. Are there plans to add these back into the tree? Those weren't just removed because they are old. A lot of them were removed because they call a function similar to mapL2toDirectoryNode, which assumes that there *is* an L2 in the system. We can put these functions back in (and I was planning on doing it as protocols are revisited), but we need to do it in a more generic way. For example, one of the things we are doing to get MESI_CMP_directory working again is removing map_L1CacheMachId_to_L2cache and replacing it with mapToAddressRange(low_bit, high_bit). Low bit and high bit are set at configuration time, and correspond to the address bits that select the L2 bank. If you could be more specific about which functions you're concerned about, we could brainstorm and come up with a new way to do the mapping. - I appreciate that a lot of the controller assumptions on the ruby side have been removed. However, it appears that Ruby now assumes a DMA controller is present. Is there plans to clean this up. I don't think Ruby actually assumes that one is present (if it does it shouldn't). The existing configuration files certainly do, though, mostly because Rocks can't run without one. If you create a configuration that doesn't instantiate a DMA controller, I think you'll be OK. The reason Rocks needs a DMA controller is mostly due to the fact that Ruby handles data now and can't just ignore DMA accesses like it used to. I don't know enough about what M5 does with DMA to know if that is a problem or not. Again, we're happy to fix this stuff up ourselves. I just want to be sure there aren't plans already in progress. Thanks, Brad ___ 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
