[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. *
[m5-dev] Adding m5 debug statements to SLICC
Hi all, I'm trying to drop in warn/inform/panic/dprintf/etc messages into the SLICC files because these functions are pretty invaluable to the being able to validate, debug and document what's going on in your simulation, but I have not been able to get them to work inside a SLICC .sm file. I was hoping that I could place a base/misc.hh header file somewhere and magic would ensue but that was not the case :) Instead, it looks like I would have to add my own detection functions for warn/inform/etc. in the SLICC parser, so that when I call those functions in the code, it will recognize it. I am wondering if anyone has had a similar problem like this (in terms of adding random C++ code to a *.sm file) and if so can you give me your perspective on what I would need to do get this working in SLICC. Is this functionality already there in SLICC and I'm just missing something? The current error I receive is this: Exception: MOESI_CMP_directory-L2cache.sm:973: Error: Unrecognized function name: 'warn': File /y/ksewell/m5-dev/m5-outgoing/SConstruct, line 1025: ... File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/ast/AST.py, line 50: self.location.error(message, *args) File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/util.py, line 72: raise Exception, %s: Error: %s % (self, message) I think this is pretty high utility, so if it's not going to be a programming adventure, I'd like to go ahead and spend time to get it working. If anyone has any thoughts or suggestions, please let me know what you think. Thanks. -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: X86: Fix the Lldt instructions so they load the...
changeset 3c628a51f6e1 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=3c628a51f6e1 description: X86: Fix the Lldt instructions so they load the ldtr and not the tr. diffstat: src/arch/x86/isa/insts/system/segmentation.py | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diffs (36 lines): diff -r f64b07758814 -r 3c628a51f6e1 src/arch/x86/isa/insts/system/segmentation.py --- a/src/arch/x86/isa/insts/system/segmentation.py Thu May 05 02:20:31 2011 -0400 +++ b/src/arch/x86/isa/insts/system/segmentation.py Fri May 06 01:00:32 2011 -0700 @@ -223,8 +223,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks reg, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, reg -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, reg +wrbase tsl, t3, dataSize=8 end: fault NoFault }; @@ -241,8 +241,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks t5, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, t5 -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, t5 +wrbase tsl, t3, dataSize=8 end: fault NoFault }; @@ -260,8 +260,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks t5, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, t5 -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, t5 +wrbase tsl, t3, dataSize=8 end: fault NoFault }; ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: X86: Fix the Lldt instructions so they load the...
Whoops, I forgot to put your name on this Tim, sorry about that. Thanks again for your help, and next time you'll get the credit you deserve. Gabe On 05/06/11 04:09, Gabe Black wrote: changeset 3c628a51f6e1 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=3c628a51f6e1 description: X86: Fix the Lldt instructions so they load the ldtr and not the tr. diffstat: src/arch/x86/isa/insts/system/segmentation.py | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diffs (36 lines): diff -r f64b07758814 -r 3c628a51f6e1 src/arch/x86/isa/insts/system/segmentation.py --- a/src/arch/x86/isa/insts/system/segmentation.py Thu May 05 02:20:31 2011 -0400 +++ b/src/arch/x86/isa/insts/system/segmentation.py Fri May 06 01:00:32 2011 -0700 @@ -223,8 +223,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks reg, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, reg -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, reg +wrbase tsl, t3, dataSize=8 end: fault NoFault }; @@ -241,8 +241,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks t5, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, t5 -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, t5 +wrbase tsl, t3, dataSize=8 end: fault NoFault }; @@ -260,8 +260,8 @@ ld t2, tsg, [8, t4, t0], 8, dataSize=8 chks t5, t1, LDTCheck wrdh t3, t1, t2 -wrdl tr, t1, t5 -wrbase tr, t3, dataSize=8 +wrdl tsl, t1, t5 +wrbase tsl, t3, dataSize=8 end: fault NoFault }; ___ 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] [m5-users] Tracing does not work
Hey Nilay, It looks like the tracing (debug) functionality is now working again, but the M5 help message is still incorrect (and extremely misleading). For instance, trace-flags, and trace-file are still accepted, but they don't do anything now. They should be eliminated from the message. We're also missing the equivalent of trace-start and trace-file. Do you mind cleaning that up? Thanks, Joel PS. I haven't followed the tracing/debugging thread closely enough, but it seems like trace and debug should be different things (though they are currently implemented as the same thing). Is there a reason why we moved over to debug? On Fri, Apr 29, 2011 at 8:28 AM, Nilay Vaish ni...@cs.wisc.edu wrote: On Fri, 29 Apr 2011, Korey Sewell wrote: Is it not now debug-help and debug-flags instead of trace-help and trace-flags??? On Fri, Apr 29, 2011 at 9:18 AM, Nilay Vaish ni...@cs.wisc.edu wrote: On Thu, 28 Apr 2011, Nilay wrote: On Thu, April 28, 2011 7:55 pm, Andrea Pellegrini wrote: Hi all, I just downloaded the latest repo from: http://repo.m5sim.org/m5 When I activate the trace functionalities through the flags nothing shows up in the output. The same command for older versions of m5 (few weeks ago) worked flawlessly. Can anybody help? Thanks -Andrea Andrea, we are aware of the problem. The solution is almost ready, and hopefully by tomorrow trace would start functioning again. -- Nilay Andrea, trace facility is working now. In fact it was fixed yesterday itself. -- Nilay ___ m5-users mailing list m5-us...@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users -- - Korey That's right, the option names have been changed. But there was some error in the trace facility it self that Nate corrected yesterday. Nilay ___ m5-users mailing list m5-us...@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users -- Joel Hestness PhD Student, Computer Architecture Dept. of Computer Science, University of Texas - Austin http://www.cs.utexas.edu/~hestness ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [m5-users] Tracing does not work
I was thinking og doing it since Nate is not around. I'll do it soon. -- Nilay On Fri, 6 May 2011, Joel Hestness wrote: Hey Nilay, It looks like the tracing (debug) functionality is now working again, but the M5 help message is still incorrect (and extremely misleading). For instance, trace-flags, and trace-file are still accepted, but they don't do anything now. They should be eliminated from the message. We're also missing the equivalent of trace-start and trace-file. Do you mind cleaning that up? Thanks, Joel PS. I haven't followed the tracing/debugging thread closely enough, but it seems like trace and debug should be different things (though they are currently implemented as the same thing). Is there a reason why we moved over to debug? ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. I have done this only for the MESI protocol so far. Once we build a consensus one the changes, I will make changes to other protocols as well. As far as testing is concerned, the protocol compiles and clears 1 loads. I did not test any more than that. A point that I wanted to raise for discussion: I think we should pull State enum and the accompanying functions into the Machine it self. Brad, what do you think? Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-L2cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-dir.sm 3c628a51f6e1 src/mem/protocol/RubySlicc_Types.sm 3c628a51f6e1 src/mem/slicc/ast/MethodCallExprAST.py 3c628a51f6e1 src/mem/slicc/symbols/StateMachine.py 3c628a51f6e1 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
Hi Nilay, Yeah, pulling the State into the Machine makes sense to me. If I recall, my previous patch made it necessary that each machine included a state_declaration (previously the state enum). More tightly integrating the state to the machine seems to be a natural progression on that path. I understand moving the permission settings back to setState is the easiest way to make this work. However, it would be great if we could combine the setting of state and the setting of permission into one function call from the sm file. Thus we don't have to worry about the situation where one sets the state, but forgets to set the permission. That could lead to some random functional access failing and a very painful debug. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Friday, May 06, 2011 3:52 PM To: Nilay Vaish; Default Subject: [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. I have done this only for the MESI protocol so far. Once we build a consensus one the changes, I will make changes to other protocols as well. As far as testing is concerned, the protocol compiles and clears 1 loads. I did not test any more than that. A point that I wanted to raise for discussion: I think we should pull State enum and the accompanying functions into the Machine it self. Brad, what do you think? Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-L2cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-dir.sm 3c628a51f6e1 src/mem/protocol/RubySlicc_Types.sm 3c628a51f6e1 src/mem/slicc/ast/MethodCallExprAST.py 3c628a51f6e1 src/mem/slicc/symbols/StateMachine.py 3c628a51f6e1 Diff: http://reviews.m5sim.org/r/684/diff Testing --- 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] Review Request: Ruby: Correctly set access permissions for directory entries
Nilay, can you explain the impact of that bug in terms of simulation performance? Are benchmarks running slower because of this change? Will regressions need to be updated? On Fri, May 6, 2011 at 8:13 PM, Beckmann, Brad brad.beckm...@amd.comwrote: Hi Nilay, Yeah, pulling the State into the Machine makes sense to me. If I recall, my previous patch made it necessary that each machine included a state_declaration (previously the state enum). More tightly integrating the state to the machine seems to be a natural progression on that path. I understand moving the permission settings back to setState is the easiest way to make this work. However, it would be great if we could combine the setting of state and the setting of permission into one function call from the sm file. Thus we don't have to worry about the situation where one sets the state, but forgets to set the permission. That could lead to some random functional access failing and a very painful debug. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Friday, May 06, 2011 3:52 PM To: Nilay Vaish; Default Subject: [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. I have done this only for the MESI protocol so far. Once we build a consensus one the changes, I will make changes to other protocols as well. As far as testing is concerned, the protocol compiles and clears 1 loads. I did not test any more than that. A point that I wanted to raise for discussion: I think we should pull State enum and the accompanying functions into the Machine it self. Brad, what do you think? Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-L2cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-dir.sm 3c628a51f6e1 src/mem/protocol/RubySlicc_Types.sm 3c628a51f6e1 src/mem/slicc/ast/MethodCallExprAST.py 3c628a51f6e1 src/mem/slicc/symbols/StateMachine.py 3c628a51f6e1 Diff: http://reviews.m5sim.org/r/684/diff Testing --- 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 -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Adding m5 debug statements to SLICC
I guess I should rephrase this question to this: What's the best way to expose a new function to be used in the *.sm SLICC files? On Fri, May 6, 2011 at 3:26 AM, Korey Sewell ksew...@umich.edu wrote: Hi all, I'm trying to drop in warn/inform/panic/dprintf/etc messages into the SLICC files because these functions are pretty invaluable to the being able to validate, debug and document what's going on in your simulation, but I have not been able to get them to work inside a SLICC .sm file. I was hoping that I could place a base/misc.hh header file somewhere and magic would ensue but that was not the case :) Instead, it looks like I would have to add my own detection functions for warn/inform/etc. in the SLICC parser, so that when I call those functions in the code, it will recognize it. I am wondering if anyone has had a similar problem like this (in terms of adding random C++ code to a *.sm file) and if so can you give me your perspective on what I would need to do get this working in SLICC. Is this functionality already there in SLICC and I'm just missing something? The current error I receive is this: Exception: MOESI_CMP_directory-L2cache.sm:973: Error: Unrecognized function name: 'warn': File /y/ksewell/m5-dev/m5-outgoing/SConstruct, line 1025: ... File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/ast/AST.py, line 50: self.location.error(message, *args) File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/util.py, line 72: raise Exception, %s: Error: %s % (self, message) I think this is pretty high utility, so if it's not going to be a programming adventure, I'd like to go ahead and spend time to get it working. If anyone has any thoughts or suggestions, please let me know what you think. Thanks. -- - Korey -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
