Re: [m5-dev] breaking up SConstruct, src/SConscript
> My usual question about does is N smaller files somehow better than 1 file > applies. I guess put another way, why is the length of this file bad? If it > logically all belongs it one place I don't feel like there is any reason to > split it up. Especially since it will probably confuse people in the future > and I've never seen site_scons used before so probably other people won't be > expecting it either. I agree that the file is pretty darned long, but I also agree that I'm not sure that simply splitting it up will make it any better. What I'd like to do in the long run is separate out the stuff that generates code from the stuff that does the various building things. I think that'd go a long way to cleaning things up. It would also potentially be cleaner if we were to create some Builders and put those in separate files. No matter what we decide, please don't even start along these lines until you talk to me first about the exact plan. I have a lot of outstanding changes in the build system, some of which may never see the light of day, and movement of large amounts of code would cause pain. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] breaking up SConstruct, src/SConscript
My usual question about does is N smaller files somehow better than 1 file applies. I guess put another way, why is the length of this file bad? If it logically all belongs it one place I don't feel like there is any reason to split it up. Especially since it will probably confuse people in the future and I've never seen site_scons used before so probably other people won't be expecting it either. Ali On Apr 11, 2011, at 3:20 AM, Gabe Black wrote: >I went digging through our SCons files today, and it occurs to me > that the two main files, SConstruct and src/SConscript, are quite long > and intimidating. They tend (as far as I could tell) to be split up into > sections which is very helpful, but there's still a sea of text and it's > easy to get disoriented and hard to get a high level idea of what's in > there and what it's all for. > >Does anyone have any objections to breaking those files into several > smaller ones, likely similar to how they're already grouped into > sections? SCons supports a site_scons directory which automatically gets > added to the python path and where you can put extra utility source > files. That seems like a good place to spin sections off into. > > Gabe > ___ > 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] AccessPermission in AbstractEntry
> -Original Message- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > On Behalf Of Nilay Vaish > Sent: Monday, April 11, 2011 2:38 PM > To: M5 Developer List > Subject: Re: [m5-dev] AccessPermission in AbstractEntry > > > > Could you elaborate on your directory controller question. I suspect > > that you are right and that only one type of directory controller can > > exist in a system, but why is that a problem? > > > > Is it not possible that we have a protocol in which different directory > controllers may behave differently? Ok, I just had a chance to look at the code and I think you a referring to the lack of a directory MACHINETYPE macro in RubySlicc_ComponentMapping.hh. Is that correct? Ideally, there shouldn't be a problem with adding any arbitrarily named controller to Ruby, as long as you incorporate the right component mapping functions into the protocol. However, in practice I suspect it will take some non-trivial amount of modifications to RubySlicc_ComponentMapping.hh. Also you'll need to be careful how Ruby and generate SLICC code uses the auto generated MachineType functions. There may be some tricky issues there. Overall, I can't really provide you a lot of specifics on why the directory MACHINETYPE macro does not exist. There may have been some assumptions behind that that were relevant in GEMS but are no longer valid in gem5. I would grep through the Ruby and generated code for the MachineType functions to fully understand the ramifications. Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: refcnt: Update doxygen comments
> On 2011-01-25 10:29:30, Ali Saidi wrote: > > i don't know that you can comment multiple functions with a singel doxygen > > comment Nate, is this on your pile to commit? - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/437/#review802 --- On 2011-01-24 17:07:56, Nathan Binkert wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/437/ > --- > > (Updated 2011-01-24 17:07:56) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > refcnt: Update doxygen comments > > I've added doxygen comments. One question: How do I make one comment apply > for multiple functions? I don't think I did that right. > > Second comment, the refcounting pointer code doesn't actually allow you to > compare/cast pointers of two different types very easily. Should we fix it? > Have people run into this problem? > > > Diffs > - > > src/base/refcnt.hh 31a04e5ac4be > > Diff: http://reviews.m5sim.org/r/437/diff > > > Testing > --- > > > Thanks, > > Nathan > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] AccessPermission in AbstractEntry
On Mon, 11 Apr 2011, Beckmann, Brad wrote: Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. I will try to make this change later today. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad Is it not possible that we have a protocol in which different directory controllers may behave differently? -- Nilay -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Sunday, April 10, 2011 2:12 AM To: m5-dev@m5sim.org Subject: [m5-dev] AccessPermission in AbstractEntry Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Add the ability to have the build directory live under the EXTRAS directory
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/606/ --- (Updated 2011-04-11 13:13:16.777354) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Add the ability to have the build directory live under the EXTRAS directory Diffs (updated) - src/SConscript d8587c913ccf Diff: http://reviews.m5sim.org/r/606/diff Testing --- I ran the standard m5 regression Thanks, brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] AccessPermission in AbstractEntry
Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad > -Original Message- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > On Behalf Of Nilay Vaish > Sent: Sunday, April 10, 2011 2:12 AM > To: m5-dev@m5sim.org > Subject: [m5-dev] AccessPermission in AbstractEntry > > Brad, it seems like the m_Permission variable in AbstractEntry is not being > used at all. In order to get AccessPermission for a state, the > state_To_AccessPermission function needs to be called. Then, why have that > variable? And this would mean that CacheMemory has no idea about the > access permission, unless we expose the state to Cache Memory class. > > Also, as it now stands, it seems one cannot have two different types of > directory controllers in a system. Is this correct? If yes, then why this > restriction? > > -- > 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: Cache warmup: fixed compile errors in Brad's cache warmup patches
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/637/#review1107 --- Hi Somayeh, It doesn't appear that your patch applies cleanly to the current tree because all I see is a javascript error. Regardless, I don't think we should add something to the repo to make those temporary patches work. I know I suggested sending a patch out for review earlier, but I was under the wrong impression that the compile issue was not a line that my patch added. My fault. Instead of adding code to the main repo to make those patches work, I suggest change the patches directly. - Brad On 2011-04-11 12:06:10, Somayeh Sardashti wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/637/ > --- > > (Updated 2011-04-11 12:06:10) > > > Review request for Default and Brad Beckmann. > > > Summary > --- > > Cache warmup: fixed compile errors in Brad's cache warmup patches > > > Diffs > - > > src/mem/ruby/network/simple/Topology.hh 955a58f51a6d > src/mem/ruby/recorder/Tracer.hh 955a58f51a6d > src/mem/ruby/system/CacheMemory.hh 955a58f51a6d > > Diff: http://reviews.m5sim.org/r/637/diff > > > Testing > --- > > > Thanks, > > Somayeh > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Cache warmup: fixed compile errors in Brad's cache warmup patches
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/637/ --- Review request for Default and Brad Beckmann. Summary --- Cache warmup: fixed compile errors in Brad's cache warmup patches Diffs - src/mem/ruby/network/simple/Topology.hh 955a58f51a6d src/mem/ruby/recorder/Tracer.hh 955a58f51a6d src/mem/ruby/system/CacheMemory.hh 955a58f51a6d Diff: http://reviews.m5sim.org/r/637/diff Testing --- Thanks, Somayeh ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] breaking up SConstruct, src/SConscript
I went digging through our SCons files today, and it occurs to me that the two main files, SConstruct and src/SConscript, are quite long and intimidating. They tend (as far as I could tell) to be split up into sections which is very helpful, but there's still a sea of text and it's easy to get disoriented and hard to get a high level idea of what's in there and what it's all for. Does anyone have any objections to breaking those files into several smaller ones, likely similar to how they're already grouped into sections? SCons supports a site_scons directory which automatically gets added to the python path and where you can put extra utility source files. That seems like a good place to spin sections off into. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Cron /z/m5/regression/do-regression quick
* build/ARM_SE/tests/fast/quick/00.hello/arm/linux/o3-timing FAILED! scons: *** Source `tests/quick/00.hello/ref/power/linux/o3-timing/stats.txt' not found, needed by target `build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing/status'. * 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/00.hello/alpha/tru64/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/tru64/simple-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/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/tru64/simple-timing-ruby 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-timing-mp 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 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 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/00.hello/alpha/linux/simple-timing-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/60.rubytest/alpha/linux/rubytest-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_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/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_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_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 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/00.hello/alpha/tru64/simple-timing-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_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-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-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest 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/simple-timing-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/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/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/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. **
