Re: [m5-dev] Review Request: scons: add a parameter to configure SCons' build cache
That depends. If you share a cache with a couple other people, yes it does. Ali On Nov 3, 2010, at 9:58 PM, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/287/#review429 --- Ship it! Looks fine to me assuming it works. Does it help much? - Steve On 2010-11-03 16:13:54, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/287/ --- (Updated 2010-11-03 16:13:54) Review request for Default. Summary --- scons: add a parameter to configure SCons' build cache Diffs - SConstruct 9d60c5339ae5 Diff: http://reviews.m5sim.org/r/287/diff Testing --- Thanks, Ali ___ 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: ARM/Alpha/Cpu: Change prefetchs to be more like normal loads.
I can do that, but I think it is a bad habit that we should change. I'm happy to do it for review, but for committing it is the wrong plan because it means that there are changesets in the repo that do not pass regressions. Ali On Nov 3, 2010, at 10:08 PM, Steve Reinhardt wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/#review431 --- Please split out the code changes and the stats changes into separate changesets (as is our habit, if not yet our official policy)... the stats changes are just too unwieldy and make it awkward to browse the code changes. Thanks! src/arch/alpha/isa/decoder.isa http://reviews.m5sim.org/r/256/#comment637 Is there still a writeHint() method out there that just doesn't ever get called now? Seems like if we're going to change the API to get rid of writeHint() and prefetch() (which seems reasonable to me) we should make sure we eliminate them thoroughly. src/cpu/simple/timing.cc http://reviews.m5sim.org/r/256/#comment636 Does swapping the order of this OR really matter? - Steve On 2010-11-03 16:13:11, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/ --- (Updated 2010-11-03 16:13:11) Review request for Default. Summary --- ARM/Alpha/Cpu: Change prefetchs to be more like normal loads. This change modifies the way prefetches work. They are now like normal loads that don't writeback a register. Previously prefetches were supposed to call prefetch() on the exection context, so they executed with execute() methods instead of initiateAcc() completeAcc(). The prefetch() methods for all the CPUs are blank, meaning that they get executed, but don't actually do anything. On Alpha dead cache copy code was removed and prefetches are now normal ops. They count as executed operations, but still don't do anything and IsMemRef is not longer set on them. On ARM IsDataPrefetch or IsInstructionPreftech is now set on all prefetch instructions. The timing simple CPU doesn't try to do anything special for prefetches now and they execute with the normal memory code path. Diffs - src/arch/alpha/isa/decoder.isa 9d60c5339ae5 src/arch/alpha/isa/mem.isa 9d60c5339ae5 src/arch/arm/isa/insts/ldr.isa 9d60c5339ae5 src/cpu/simple/timing.cc 9d60c5339ae5 src/cpu/static_inst.hh 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simerr 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/stats.txt 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/stats.txt 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/config.ini 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simout 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/simout 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/simerr 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/simout 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-timing/config.ini 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-timing/simout 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-timing/stats.txt 9d60c5339ae5 tests/long/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/40.perlbmk/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/40.perlbmk/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/40.perlbmk/ref/alpha/tru64/simple-atomic/simerr
[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/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 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. * 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_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory 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/50.memtest/alpha/linux/memtest-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_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_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory 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/00.hello/alpha/tru64/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_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token 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/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/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-atomic 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/simple-timing 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-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing 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/o3-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 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/o3-timing-mp passed. *
Re: [m5-dev] Status of ARM support
Hi Tim, With the changes I'll get in in the next few days M5 can boot linux with a single simple atomic or simple timing CPU. The file system is loaded into some of the DRAM and the slram device driver is used. Support for a dumb PATA device that only supports PIO should be added soon too. We're working on O3, and MP support which will hopefully be done by the end of this year. Thanks, Ali On Nov 3, 2010, at 7:37 PM, Timothy M Jones wrote: Hi Ali, Could you tell me roughly what the status of ARM support is for full-system simulation? I'm thinking of using M5 ARM for a future project (which won't start until sometime next year) and I will want a simulator that I can run Linux on. Cheers Tim -- Timothy M. Jones http://homepages.inf.ed.ac.uk/tjones1 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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] Implementation of findTagInSet
I tried running ruby_fs.py, below is the error message that I received. I don't think there is any documentation or mailing list discussion on how to run ruby_fs.py. To me it seems that some parameter relating to the DMA controller is missing from the command I tried out. -- Nilay ./build/ALPHA_FS/m5.prof ./configs/example/ruby_fs.py -n 1 --detailed --caches --l2cache -F 50M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Nov 3 2010 18:10:26 M5 revision 3b2f82286e5d 7724 default WarnPatch qtip tip M5 started Nov 4 2010 08:50:01 M5 executing on scamorza.cs.wisc.edu command line: ./build/ALPHA_FS/m5.prof ./configs/example/ruby_fs.py -n 1 --detailed --caches --l2cache -F 50 Error: could not create sytem for ruby protocol MI_example Traceback (most recent call last): File string, line 1, in ? File /scratch/nilay/GEM5/sibling/src/python/m5/main.py, line 359, in main exec filecode in scope File ./configs/example/ruby_fs.py, line 117, in ? system._dma_devices) File /scratch/nilay/GEM5/sibling/configs/ruby/Ruby.py, line 69, in create_system (cpu_sequencers, dir_cntrls, all_cntrls) = \ File string, line 0, in ? File /scratch/nilay/GEM5/sibling/configs/ruby/MI_example.py, line 138, in create_system system.dma_cntrl.dma_sequencer.port = dma_device.dma File /scratch/nilay/GEM5/sibling/src/python/m5/SimObject.py, line 586, in __getattr__ raise AttributeError, object '%s' has no attribute '%s' \ AttributeError: object 'LinuxAlphaSystem' has no attribute 'dma_cntrl' On Wed, 3 Nov 2010, Steve Reinhardt wrote: Ah, the issue is that you're using the old M5 memory hierarchy and not Ruby. You need to run one of the Ruby versions, and use ruby_fs.py instead of fs.py. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ARM/Alpha/Cpu: Change prefetchs to be more like normal loads.
On 2010-11-03 20:08:42, Steve Reinhardt wrote: Please split out the code changes and the stats changes into separate changesets (as is our habit, if not yet our official policy)... the stats changes are just too unwieldy and make it awkward to browse the code changes. Thanks! I'll post the code changes separately, but when it comes to committing the change I think we should commit code and stats changes together. The goal should be the repository passes regressions at every revision. On 2010-11-03 20:08:42, Steve Reinhardt wrote: src/cpu/simple/timing.cc, line 765 http://reviews.m5sim.org/r/256/diff/2/?file=4905#file4905line765 Does swapping the order of this OR really matter? Sorry, no... that is what I get for not paying enough attention to my diff. I'll remove that part of it. On 2010-11-03 20:08:42, Steve Reinhardt wrote: src/arch/alpha/isa/decoder.isa, line 791 http://reviews.m5sim.org/r/256/diff/2/?file=4902#file4902line791 Is there still a writeHint() method out there that just doesn't ever get called now? Seems like if we're going to change the API to get rid of writeHint() and prefetch() (which seems reasonable to me) we should make sure we eliminate them thoroughly. prefetch() I'm happy with axing. If we wanted to do a write hint type operation in the future, how would we do it? We could do a cache block sized store, in which case I'm happy to axe it too... - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/#review431 --- On 2010-11-03 16:13:11, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/ --- (Updated 2010-11-03 16:13:11) Review request for Default. Summary --- ARM/Alpha/Cpu: Change prefetchs to be more like normal loads. This change modifies the way prefetches work. They are now like normal loads that don't writeback a register. Previously prefetches were supposed to call prefetch() on the exection context, so they executed with execute() methods instead of initiateAcc() completeAcc(). The prefetch() methods for all the CPUs are blank, meaning that they get executed, but don't actually do anything. On Alpha dead cache copy code was removed and prefetches are now normal ops. They count as executed operations, but still don't do anything and IsMemRef is not longer set on them. On ARM IsDataPrefetch or IsInstructionPreftech is now set on all prefetch instructions. The timing simple CPU doesn't try to do anything special for prefetches now and they execute with the normal memory code path. Diffs - src/arch/alpha/isa/decoder.isa 9d60c5339ae5 src/arch/alpha/isa/mem.isa 9d60c5339ae5 src/arch/arm/isa/insts/ldr.isa 9d60c5339ae5 src/cpu/simple/timing.cc 9d60c5339ae5 src/cpu/static_inst.hh 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simerr 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/stats.txt 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-timing/stats.txt 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/config.ini 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/simout 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/stats.txt 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/simout 9d60c5339ae5 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/simerr 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/simout 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-atomic/stats.txt 9d60c5339ae5 tests/long/30.eon/ref/alpha/tru64/simple-timing/config.ini 9d60c5339ae5
[m5-dev] Statistics Output Conventions
Hi, I'm currently trying to leverage a Python script and McPAT to consume M5 statistics (stats.txt) and calculate power estimates for a simulated system. Stats variables in the SimObjects are lowerCamelCase according to the coding style, but it looks like the names output to the stats.txt file are mixed, either lowerCamelCase or lower_case_with_underscores. I'm wondering if there is a convention for statistic names that are output to the stats.txt that I (we) can be aiming for. Thanks, Joel -- 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] Implementation of findTagInSet
You also have to build a binary that supports ruby, like ALPHA_FS_MOESI_hammer. If you can't get that to work, try ALPHA_SE_MOESI_hammer and run one of the ALPHA_SE test workloads... the workload you run doesn't really matter that much as long as it's long enough to get a meaningful profile. Steve On Thu, Nov 4, 2010 at 7:17 AM, Nilay Vaish ni...@cs.wisc.edu wrote: I tried running ruby_fs.py, below is the error message that I received. I don't think there is any documentation or mailing list discussion on how to run ruby_fs.py. To me it seems that some parameter relating to the DMA controller is missing from the command I tried out. -- Nilay ./build/ALPHA_FS/m5.prof ./configs/example/ruby_fs.py -n 1 --detailed --caches --l2cache -F 50M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Nov 3 2010 18:10:26 M5 revision 3b2f82286e5d 7724 default WarnPatch qtip tip M5 started Nov 4 2010 08:50:01 M5 executing on scamorza.cs.wisc.edu command line: ./build/ALPHA_FS/m5.prof ./configs/example/ruby_fs.py -n 1 --detailed --caches --l2cache -F 50 Error: could not create sytem for ruby protocol MI_example Traceback (most recent call last): File string, line 1, in ? File /scratch/nilay/GEM5/sibling/src/python/m5/main.py, line 359, in main exec filecode in scope File ./configs/example/ruby_fs.py, line 117, in ? system._dma_devices) File /scratch/nilay/GEM5/sibling/configs/ruby/Ruby.py, line 69, in create_system (cpu_sequencers, dir_cntrls, all_cntrls) = \ File string, line 0, in ? File /scratch/nilay/GEM5/sibling/configs/ruby/MI_example.py, line 138, in create_system system.dma_cntrl.dma_sequencer.port = dma_device.dma File /scratch/nilay/GEM5/sibling/src/python/m5/SimObject.py, line 586, in __getattr__ raise AttributeError, object '%s' has no attribute '%s' \ AttributeError: object 'LinuxAlphaSystem' has no attribute 'dma_cntrl' On Wed, 3 Nov 2010, Steve Reinhardt wrote: Ah, the issue is that you're using the old M5 memory hierarchy and not Ruby. You need to run one of the Ruby versions, and use ruby_fs.py instead of fs.py. Steve ___ 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: ARM/Alpha/Cpu: Change prefetchs to be more like normal loads.
On Thu, Nov 4, 2010 at 9:41 AM, Ali Saidi sa...@umich.edu wrote: On 2010-11-03 20:08:42, Steve Reinhardt wrote: Please split out the code changes and the stats changes into separate changesets (as is our habit, if not yet our official policy)... the stats changes are just too unwieldy and make it awkward to browse the code changes. Thanks! I'll post the code changes separately, but when it comes to committing the change I think we should commit code and stats changes together. The goal should be the repository passes regressions at every revision. I saw your earlier mail and you have a good point but after some reflection I still don't agree. It sounds good to say that every revision should pass regressions, but in practice I don't know how much that matters. I certainly think that every revision should compile and run, because otherwise 'hg bisect' is a pain, but I've never used bisect to track down when a regression started failing... I guess it's possible, but if regressions are running regularly then we should catch failures soon enough that it's not such a mystery where things went wrong. Meanwhile it's nice to just be able to ignore the csets that are labeled as stats updates and not wade through them to find actual code changes. Perhaps even more compelling is that there are a number of times where people (including me) have made some pretty substantive changes that are spread out across several csets, and it's a big enough pain to regenerate stats that you really only want to do it once for a related sequence of changes, and once you cross that bridge then you're admitting that you're not going to have regressions pass at every rev. On 2010-11-03 20:08:42, Steve Reinhardt wrote: src/cpu/simple/timing.cc, line 765 http://reviews.m5sim.org/r/256/diff/2/?file=4905#file4905line765 Does swapping the order of this OR really matter? Sorry, no... that is what I get for not paying enough attention to my diff. I'll remove that part of it. On 2010-11-03 20:08:42, Steve Reinhardt wrote: src/arch/alpha/isa/decoder.isa, line 791 http://reviews.m5sim.org/r/256/diff/2/?file=4902#file4902line791 Is there still a writeHint() method out there that just doesn't ever get called now? Seems like if we're going to change the API to get rid of writeHint() and prefetch() (which seems reasonable to me) we should make sure we eliminate them thoroughly. prefetch() I'm happy with axing. If we wanted to do a write hint type operation in the future, how would we do it? We could do a cache block sized store, in which case I'm happy to axe it too... I don't think writeHint() does anything anyway. If we want to add it back in we could just add a special flag to a write operation, which would be more consistent with other prefetches anyway. Steve - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/#review431 --- On 2010-11-03 16:13:11, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/256/ --- (Updated 2010-11-03 16:13:11) Review request for Default. Summary --- ARM/Alpha/Cpu: Change prefetchs to be more like normal loads. This change modifies the way prefetches work. They are now like normal loads that don't writeback a register. Previously prefetches were supposed to call prefetch() on the exection context, so they executed with execute() methods instead of initiateAcc() completeAcc(). The prefetch() methods for all the CPUs are blank, meaning that they get executed, but don't actually do anything. On Alpha dead cache copy code was removed and prefetches are now normal ops. They count as executed operations, but still don't do anything and IsMemRef is not longer set on them. On ARM IsDataPrefetch or IsInstructionPreftech is now set on all prefetch instructions. The timing simple CPU doesn't try to do anything special for prefetches now and they execute with the normal memory code path. Diffs - src/arch/alpha/isa/decoder.isa 9d60c5339ae5 src/arch/alpha/isa/mem.isa 9d60c5339ae5 src/arch/arm/isa/insts/ldr.isa 9d60c5339ae5 src/cpu/simple/timing.cc 9d60c5339ae5 src/cpu/static_inst.hh 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/simout 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/config.ini 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simerr 9d60c5339ae5 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/simout
Re: [m5-dev] Statistics Output Conventions
On Thu, Nov 4, 2010 at 12:21 PM, nathan binkert n...@binkert.org wrote: I'm currently trying to leverage a Python script and McPAT to consume M5 statistics (stats.txt) and calculate power estimates for a simulated system. Stats variables in the SimObjects are lowerCamelCase according to the coding style, but it looks like the names output to the stats.txt file are mixed, either lowerCamelCase or lower_case_with_underscores. I'm wondering if there is a convention for statistic names that are output to the stats.txt that I (we) can be aiming for. I don't think we have the convention written down, but I'd prefer that the names of the stats match their output. I'd prefer if stats names were all lower_with_underscore since it would easily differentiate a stat from a regular variable. Anyone else have an opinion? I think the current situation is basically historical... the stats names with underscores were inherited from SimpleScalar, and then we we went with camelCase for variable names there was an inherent mismatch that has at times been perpetuated and at other times ignored. It would be nice to have an official policy and to follow it for new stats, and also go back and fix up existing stats to be consistent with that policy. I'm not a big fan of having stats variables be lower_with_underscores since we already are supposed to be using that to distinguish local variables from class members (though we're not very consistent about that either). If there's a desire to make the stats vars consistent with the stats names, my preference would be to make the stats names camelCase, but I can see where that could cause a lot of work for people who have scripts that process stats.txt. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ARM/Alpha/Cpu: Change prefetchs to be more like normal loads.
I was planning to send an e-mail that more or less says these same things, so I agree with Steve. Nate I saw your earlier mail and you have a good point but after some reflection I still don't agree. It sounds good to say that every revision should pass regressions, but in practice I don't know how much that matters. I certainly think that every revision should compile and run, because otherwise 'hg bisect' is a pain, but I've never used bisect to track down when a regression started failing... I guess it's possible, but if regressions are running regularly then we should catch failures soon enough that it's not such a mystery where things went wrong. Meanwhile it's nice to just be able to ignore the csets that are labeled as stats updates and not wade through them to find actual code changes. Perhaps even more compelling is that there are a number of times where people (including me) have made some pretty substantive changes that are spread out across several csets, and it's a big enough pain to regenerate stats that you really only want to do it once for a related sequence of changes, and once you cross that bridge then you're admitting that you're not going to have regressions pass at every rev. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Statistics Output Conventions
I think the current situation is basically historical... the stats names with underscores were inherited from SimpleScalar, and then we we went with camelCase for variable names there was an inherent mismatch that has at times been perpetuated and at other times ignored. True. It would be nice to have an official policy and to follow it for new stats, and also go back and fix up existing stats to be consistent with that policy. I'm not a big fan of having stats variables be lower_with_underscores since we already are supposed to be using that to distinguish local variables from class members (though we're not very consistent about that either). If there's a desire to make the stats vars consistent with the stats names, my preference would be to make the stats names camelCase, but I can see where that could cause a lot of work for people who have scripts that process stats.txt. I have a slight preference to come up with some way to differentiate state vars from regular member vars. The reason is that people try to use stats like normal vars and are confused when it doesn't work. Perhaps this is no big deal though. Changing names might not be so nice because of scripts, but it'd be nice to get consistent (and do it once.) One inconsistency we also have is that most objects in config files are lower_with_under, and having stat vars match that means that foo.bar_blah.stat_with_under looks a bit better than foo.bar_blah.statCamelCase. One thing I feel strongly about is that stat names and variable names should be valid identifiers in both python and C++. We currently have some stats with :: in them and that's no good. Nate Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
