[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-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 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-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-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-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/30.eio-mp/alpha/eio/simple-timing-mp 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/tests/fast/quick/60.rubytest/alpha/linux/rubytest-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 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-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 passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 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-atomic passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
Re: [m5-dev] Review Request: ARM: Fix checkpoint restoration into O3 CPU and the way O3 switchCpu works.
Everyone, this change alters the way that the O3 cpu switches registers from the atomic cpu. If you use checkpoint/switchover and m5 please test this (specifically the change to src/cpu/o3/thread_context_impl.hh) Thanks, Ali On Mar 30, 2011, at 4:55 PM, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/620/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ARM: Fix checkpoint restoration into O3 CPU and the way O3 switchCpu works. This change fixes a small bug in the arm copyRegs() code where some registers wouldn't be copied if the processor was in a mode other than MODE_USER. Additionally, this change simplifies the way the O3 switchCpu code works by utilizing TheISA::copyRegs() to copy the required context information rather than the adhoc copying that goes on in the CPU model. The current code makes assumptions about the visibility of int and float registers that aren't true for all architectures in FS mode. Diffs - src/arch/arm/isa.cc d54b7775a6b0 src/arch/arm/miscregs.hh d54b7775a6b0 src/arch/arm/utility.cc d54b7775a6b0 src/cpu/o3/thread_context_impl.hh d54b7775a6b0 Diff: http://reviews.m5sim.org/r/620/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
[m5-dev] trace compression
I just realized today that m5 can automatically compress the trace output generated by traceflags. Since I didn't realize this worked I've added to the documentation, but I thought I would also share it with the list: Trace file can become rather large quickly, but they do compress very well (e.g. about 90%). If you'd like to make m5 output a compressed trace, just name the trace output file with a .gz ending. For example --trace-file=trace.out will produce an uncompressed file as normal, but --trace-file=trace.out.gz will produce a gzip compressed file. You can then manipulate these files with zcat and pipes to process the output. The editor vim also can uncompress gzip compressed files in memory which can be useful. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: patch from Vince Weaver for review
On 2011-03-18 13:54:12, Gabe Black wrote: It seems like we should be able to emulate the access system call fairly easily. It basically just checks if a file can be accessed in certain ways, I think. We could do that on the real file descriptor, rearrange the result if necessary, and pass it back. The other syscall changes here look ok. Would you object to committing/pushing as is and emulating access() if it ever becomes necessary in the future? It's not something I'm going to commit to doing, and I wouldn't want everything else to get held up because of it. - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/588/#review980 --- On 2011-03-17 16:05:56, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/588/ --- (Updated 2011-03-17 16:05:56) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86: SE syscalls: patch from Vince Weaver for review Diffs - src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/588/diff Testing --- I've done minimal testing on these, i.e. I've pushed them to a clean tree and run X86 SPEC2k6 binaries on them, some of which didn't work prior to the patches but now do. Others remain broken. Vince, however, has done lots of testing and basically needed these to run SPEC2K workloads to completion for his thesis. In other words, I bet these patches are good, but not complete for the purposes of running SPEC2k6. Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: X86: fsincos: Another patch from Vince Weaver
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/593/#review1057 --- Since there have been no objections, I'm going to commit this. - Lisa On 2011-03-17 16:07:17, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/593/ --- (Updated 2011-03-17 16:07:17) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86: fsincos: Another patch from Vince Weaver Diffs - src/arch/x86/isa/decoder/x87.isa 2e269d6fb3e6 src/arch/x86/isa/insts/x87/transcendental_functions/trigonometric_functions.py 2e269d6fb3e6 src/arch/x86/isa/microops/fpop.isa 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/593/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: X86: haddps: Another patch from Vince Weaver
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/592/#review1058 --- Since there have been no objections, I'm going to commit this. - Lisa On 2011-03-17 16:07:08, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/592/ --- (Updated 2011-03-17 16:07:08) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86: haddps: Another patch from Vince Weaver Diffs - src/arch/x86/isa/decoder/two_byte_opcodes.isa 2e269d6fb3e6 src/arch/x86/isa/insts/simd128/floating_point/arithmetic/horizontal_addition.py 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/592/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: X86: rlimit: Another patch from Vince Weaver
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/591/#review1059 --- Since there have been no objections, I'm going to commit this. - Lisa On 2011-03-17 16:06:30, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/591/ --- (Updated 2011-03-17 16:06:30) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86: rlimit: Another patch from Vince Weaver Diffs - src/arch/x86/linux/linux.hh 2e269d6fb3e6 src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/591/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver
On 2011-03-18 13:57:35, Gabe Black wrote: src/sim/syscall_emul.hh, line 503 http://reviews.m5sim.org/r/589/diff/1/?file=11013#file11013line503 Why is this change necessary? I'm not 100% sure why it was the way it was before, but I see no reason to change it either. Changing the fatal to a warn may be necessary to get some benchmark to run, but I'm talking specifically about the ones that would return -ENOTTY. Vince Weaver wrote: It's been a while, but let's see if I can see what's going on. Before we had a short list of ioctls we return -ENOTTY for, any not on the list gave a fatal error. ENOTTY if I recall correctly is the typical way the kernel reports an ioctl not being implemented. So by changing all ioctls to warn and then report ENOTTY we are saying that we don't support it, but the program can keep running assuming it handles an ENOTTY properly. For most of the SPEC benchmarks ioctl() calls aren't important for correctness, so this works. We could go back to having a whitelist of known-to-be-OK-to-ignore ioctls(), but it might turn out to be a lengthy list, and also we probably should implement things like isatty() properly as I do think some benchmarks depend on it returning the right value (see http://www.cs.binghamton.edu/~msim/wiki/index.php/TIOCISATTY ) Gabe Black wrote: isatty is actually pretty annoying, and it's important that it -not- always return the right answer. It needs to be consistent regardless of whether your piping output to a file or watching it on the console so runs are deterministic, and if it always thinks it's going to a tty it'll buffer properly for when it's actually going to a tty (and doesn't look like something's broken, basically) and just perform a little worse when it's not. As far as simulator performance it doesn't matter since I'm sure it's a long way from being the critical path, and it should be a reasonable situation as far as simulated performance. I think a whitelist is a good idea, and we don't have to have -all- the ok to ignore ones on there, just the ok to ignore ones that actually get called. That should be a lot more manageable list. That way you know if something out of the ordinary is happening (the simulator will bomb out) rather than something weird happening and the benchmark stumbling on to eventually die, potentially far from evidence of what happened. The later is a lot harder to debug. Steve Reinhardt wrote: ENOTTY is just the way the kernel reports a TTY-specific ioctl being invoked on a non-TTY device. Gabe is right that for repeatability you always want the simulator to always act like there's no tty for determinism. I would prefer to see us figure out what other ioctls need to be added to the TTY-specific list than to make a blanket assumption that any ioctl that's called is TTY-specific. So, what's the consensus here? No checkin until ioctls are better figured out? - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/589/#review981 --- On 2011-03-17 16:06:13, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/589/ --- (Updated 2011-03-17 16:06:13) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86 ioctl: Another patch from Vince Weaver Diffs - src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 src/sim/syscall_emul.hh 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/589/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Ruby: Protocol.hh
I am wondering what's the need of the file Protocol.hh, I removed it from different in the protocol independent part of Ruby. I also removed the file standard_1level_CMP-protocol.sm from the MOESI_hammer.slicc. Everything compiles perfectly. I am not sure what the requirement is. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1054 --- Hi Nilay, First, thanks for your patience. Sorry I wasn't able to provide you comments sooner. Overall, this patch is definitely what I had in mind and is a good starting point. I have several comments/questions below. Please let me know if you need me to clarify anything. src/mem/ruby/system/AbstractMemory.hh http://reviews.m5sim.org/r/611/#comment1425 Instead of having canMakeFunctionalAccess do some internal analysis and return a boolean result, why not simply pass back the AccessPermission? The status of the address for a particular memory object does not indicate whether a functional access is possible. Rather it is the collective status across all memory objects which determine whether the functional access is possible. src/mem/ruby/system/CacheMemory.cc http://reviews.m5sim.org/r/611/#comment1426 Again, I think this type of analysis should be moved the RubyPort, but I do want to point out that functional accesses have different constraints than real accesses. Even if the AccessPermission is Read_Only, a functional access can succeed and should update the block. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1427 Eventually, we'll need to change recvFunctional to return a bool indicating whether the access was successful. I suspect the ramifications of the change will be rather significant across gem5, so for now it is fine to just return void. However, eventually we will need to address this larger issue. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1421 Are you just pushing a lable here for debug purposes? Does this have any impact on the actual functionality? src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1428 This loop is probably the most complicated and important part of this patch. It might be easiest if we move this functionality into two different functions, one for reads and one for writes. The read scan just needs to ensure that at least one memory says that it has the address in Read_Only or ReadWrite state. We may also want to doublecheck that multiple memories say they have the address in ReadWrite state. The write scan is more complicated. If one memory says that it has the address in ReadWrite state, then I don't think it matters what state the other memories are in (except of course if another memory says it also has the address in ReadWrite), the write should succeed. Also if the write scans says that all copies are in Read_Only or Invalid/NotPresent state and no copies are Busy, the write should succeed. However, writes should fail if either no Read_Only or ReadWrite copies are found, or if a Busy copy is found and no ReadWrite copy is found. The latter situation will likely indicate the functional write is racing with a timing write. There is no easy, protocol-agnostic way to resolve such a race in the current infrastructure. Make sense? src/mem/ruby/system/System.hh http://reviews.m5sim.org/r/611/#comment1423 Why is this a static function? It seems unecessary and it prevents us from using ruby in multiple systems. - Brad On 2011-03-30 16:19:26, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-30 16:19:26) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py d54b7775a6b0 configs/ruby/Ruby.py d54b7775a6b0 src/mem/ruby/network/Network.cc d54b7775a6b0 src/mem/ruby/network/Network.py d54b7775a6b0 src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 src/mem/ruby/profiler/Profiler.py d54b7775a6b0 src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 src/mem/ruby/recorder/Tracer.py d54b7775a6b0 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py d54b7775a6b0 src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 src/mem/ruby/system/RubyPort.hh d54b7775a6b0 src/mem/ruby/system/RubyPort.cc d54b7775a6b0 src/mem/ruby/system/RubySystem.py d54b7775a6b0 src/mem/ruby/system/SConscript d54b7775a6b0 src/mem/ruby/system/Sequencer.py
[m5-dev] Review Request: Ruby: pass Packet-Req-contextId() to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: pass Packet-Req-contextId() to Ruby. It is useful for Ruby to understand from whence request packets came. This has all request packets going into Ruby pass the contextId value, if it exists. This supplants the old libruby proc_id value passed around in all the Messages, so I've also removed the unused unsigned proc_id; member generated by SLICC for all Message types. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf src/mem/ruby/system/Sequencer.cc d8587c913ccf src/mem/slicc/symbols/Type.py d8587c913ccf Diff: http://reviews.m5sim.org/r/623/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: have the rubytester pass contextId to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: have the rubytester pass contextId to Ruby. Diffs - src/cpu/testers/rubytest/Check.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/625/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Add new object called WireBuffer to mimic a Wire.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/SConscript d8587c913ccf src/mem/ruby/system/SConscript d8587c913ccf src/mem/ruby/system/WireBuffer.hh PRE-CREATION src/mem/ruby/system/WireBuffer.cc PRE-CREATION src/mem/ruby/system/WireBuffer.py PRE-CREATION src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/627/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/628/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/628/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/system/CacheMemory.hh d8587c913ccf src/mem/ruby/system/CacheMemory.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/629/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: pass Packet-Req-contextId() to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/#review1060 --- Ship it! Is context Id being used any where? - Nilay On 2011-03-31 12:16:27, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/ --- (Updated 2011-03-31 12:16:27) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: pass Packet-Req-contextId() to Ruby. It is useful for Ruby to understand from whence request packets came. This has all request packets going into Ruby pass the contextId value, if it exists. This supplants the old libruby proc_id value passed around in all the Messages, so I've also removed the unused unsigned proc_id; member generated by SLICC for all Message types. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf src/mem/ruby/system/Sequencer.cc d8587c913ccf src/mem/slicc/symbols/Type.py d8587c913ccf Diff: http://reviews.m5sim.org/r/623/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
Hi Lisa, I actually had sent the attachments to Brad since m5dev bounced the attachments. I think the limit is 512kB or something like that. But definitely, thanks for the heads up! On Wed, Mar 30, 2011 at 7:45 PM, Lisa Hsu h...@eecs.umich.edu wrote: I think you forgot the attachments :P. Sometimes, if ProtocolTrace isn't enough for me to find a problem, I turn on RubySlicc and RubyGenerated as well. RubySlicc is the DPRINTFs within the actual protocol *.sm files, and RubyGenerated are inside of the generated code that you will only see in the build directory. Lisa On Tue, Mar 29, 2011 at 10:15 AM, Korey Sewell ksew...@umich.edu wrote: Thanks for the response Brad. The 1st trace has 1 L2 and the 2nd has 1 L2 (i had a typo in the original email). For each trace, I attach the stdout/stderr (*.out) and then the protocol trace (*.prottrace). Also, in the 1st trace, the offending address is clear and I isolate that in the protocol trace file provided. However, in the 2nd trace, it's unclear (currently) which access caused it to fail so I took the whole protocol trace file and gzip'd it. My current lack of expertise in SLICC limits me a bit, but I'd like to be more helpful in debugging so if there is anything that I can look into (or run) on my end to expedite the process, please advise. In the interim, I'll try to locate the exact address that's breaking trace 2 and then hopefully repost that. Thanks! -Korey On Tue, Mar 29, 2011 at 12:02 PM, Beckmann, Brad brad.beckm...@amd.com wrote: Hi Korey, I believe both of these issues should be easy to solve once we have a protocol trace leading up to the error. If you could create such a trace and send it to the list, that would be great. Just zero in on the offending address. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Tuesday, March 29, 2011 8:11 AM To: M5 Developer List Subject: [m5-dev] Running Ruby w/32 Cores Hi All, I'm still having a bit of trouble running Ruby with 32+ cores. I am experimenting w/configs varying the l2-caches. The runs seems to generate various errors in the SLICC. Has anybody seen these or have any insight to how to start solving these type of issues (posted below)? = The command line and errors are as follows: (1) 32 Cores and 32 L2s build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... info: Entering event queue @ 0. Starting simulation... Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: assert failure, PID: 5990 press return to continue. Program aborted at cycle 19139500 Aborted (2) 32 Cores and 1 L2 build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... fatal: Invalid transition system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack state: MM @ cycle 174537500 [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protoc ol/L1Cache_Transitions.cc, line 477] Memory Usage: 2316756 KBytes For more information see: http://www.m5sim.org/fatal/23f196b2 Please let me know if you do...Thanks! -- - Korey ___ 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 -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
Is there an attached patch I should be running or did it get bounced by m5-dev? If so, can you send it directly to me rather through m5-dev? On Wed, Mar 30, 2011 at 8:26 PM, Beckmann, Brad brad.beckm...@amd.com wrote: Hi Korey, For the first trace, it looks like the L2 cache is either miscounting the number of valid L1 copies, or there is an error with the ack arithmetic. We are going to need a bit more information to figure out where the exact problem is. Could you apply the attached patch and reply with the new protocol trace? Thanks. For the second trace, you should be able to get the offending address by simply attaching GDB to the aborted process. Without knowing which address to zero in on, it is the proverbial finding a needle in a haystack. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Tuesday, March 29, 2011 10:15 AM To: M5 Developer List Subject: Re: [m5-dev] Running Ruby w/32 Cores Thanks for the response Brad. The 1st trace has 1 L2 and the 2nd has 1 L2 (i had a typo in the original email). For each trace, I attach the stdout/stderr (*.out) and then the protocol trace (*.prottrace). Also, in the 1st trace, the offending address is clear and I isolate that in the protocol trace file provided. However, in the 2nd trace, it's unclear (currently) which access caused it to fail so I took the whole protocol trace file and gzip'd it. My current lack of expertise in SLICC limits me a bit, but I'd like to be more helpful in debugging so if there is anything that I can look into (or run) on my end to expedite the process, please advise. In the interim, I'll try to locate the exact address that's breaking trace 2 and then hopefully repost that. Thanks! -Korey On Tue, Mar 29, 2011 at 12:02 PM, Beckmann, Brad brad.beckm...@amd.com wrote: Hi Korey, I believe both of these issues should be easy to solve once we have a protocol trace leading up to the error. If you could create such a trace and send it to the list, that would be great. Just zero in on the offending address. Thanks, Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev- boun...@m5sim.org] On Behalf Of Korey Sewell Sent: Tuesday, March 29, 2011 8:11 AM To: M5 Developer List Subject: [m5-dev] Running Ruby w/32 Cores Hi All, I'm still having a bit of trouble running Ruby with 32+ cores. I am experimenting w/configs varying the l2-caches. The runs seems to generate various errors in the SLICC. Has anybody seen these or have any insight to how to start solving these type of issues (posted below)? = The command line and errors are as follows: (1) 32 Cores and 32 L2s build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... info: Entering event queue @ 0. Starting simulation... Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: assert failure, PID: 5990 press return to continue. Program aborted at cycle 19139500 Aborted (2) 32 Cores and 1 L2 build/ALPHA_FS_MOESI_CMP_directory/m5.opt configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- l2caches=32 ... fatal: Invalid transition system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack state: MM @ cycle 174537500 [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protoc ol/L1Cache_Transitions.cc, line 477] Memory Usage: 2316756 KBytes For more information see: http://www.m5sim.org/fatal/23f196b2 Please let me know if you do...Thanks! -- - Korey ___ 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 -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Bug in SLICC forgot semicolon at end of c...
changeset 99428f716e7b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=99428f716e7b
description:
Ruby: Bug in SLICC forgot semicolon at end of code.
diffstat:
src/mem/slicc/symbols/StateMachine.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diffs (12 lines):
diff -r d54b7775a6b0 -r 99428f716e7b src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Tue Mar 29 19:36:36 2011 -0400
+++ b/src/mem/slicc/symbols/StateMachine.py Thu Mar 31 12:20:16 2011 -0700
@@ -605,7 +605,7 @@
# Set randomization
if random in var:
# A buffer
-code('$vid-setRandomization(${{var[random]}})')
+code('$vid-setRandomization(${{var[random]}});')
# Set Priority
if rank in var:
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: pass Packet-Req-contextId() to Ruby.
On 2011-03-31 12:27:47, Nilay Vaish wrote: Is context Id being used any where? Not in any of the stock-provided protocols, but in some of our internal protocols, yes. This would also enable anyone to do context-based cache management, if they so desired, though it's not in the tree at all. This is just to provide the functionality, now people can use it however they want! - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/#review1060 --- On 2011-03-31 12:16:27, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/ --- (Updated 2011-03-31 12:16:27) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: pass Packet-Req-contextId() to Ruby. It is useful for Ruby to understand from whence request packets came. This has all request packets going into Ruby pass the contextId value, if it exists. This supplants the old libruby proc_id value passed around in all the Messages, so I've also removed the unused unsigned proc_id; member generated by SLICC for all Message types. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf src/mem/ruby/system/Sequencer.cc d8587c913ccf src/mem/slicc/symbols/Type.py d8587c913ccf Diff: http://reviews.m5sim.org/r/623/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/628/ --- (Updated 2011-03-31 14:13:38.794443) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs (updated) - src/mem/slicc/ast/ActionDeclAST.py 7ee8e012c038 src/mem/slicc/ast/FormalParamAST.py 7ee8e012c038 src/mem/slicc/ast/FuncCallExprAST.py 7ee8e012c038 src/mem/slicc/ast/IsValidPtrExprAST.py 7ee8e012c038 src/mem/slicc/ast/MemberExprAST.py 7ee8e012c038 Diff: http://reviews.m5sim.org/r/628/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1062 --- Ship it! - Nilay On 2011-03-31 12:21:22, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/ --- (Updated 2011-03-31 12:21:22) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/system/CacheMemory.hh d8587c913ccf src/mem/ruby/system/CacheMemory.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/629/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add new object called WireBuffer to mimic a Wire.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/#review1063 --- src/mem/ruby/system/WireBuffer.hh http://reviews.m5sim.org/r/627/#comment1430 Remove the comment. src/mem/ruby/system/WireBuffer.hh http://reviews.m5sim.org/r/627/#comment1431 Remove this line as well. src/mem/ruby/system/WireBuffer.py http://reviews.m5sim.org/r/627/#comment1429 Do we need this commented piece of code? - Nilay On 2011-03-31 12:21:07, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/ --- (Updated 2011-03-31 12:21:07) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/SConscript d8587c913ccf src/mem/ruby/system/SConscript d8587c913ccf src/mem/ruby/system/WireBuffer.hh PRE-CREATION src/mem/ruby/system/WireBuffer.cc PRE-CREATION src/mem/ruby/system/WireBuffer.py PRE-CREATION src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/627/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: have the rubytester pass contextId to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/#review1064 --- Ship it! - Nilay On 2011-03-31 12:20:59, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/ --- (Updated 2011-03-31 12:20:59) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: have the rubytester pass contextId to Ruby. Diffs - src/cpu/testers/rubytest/Check.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/625/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1065 --- Ship it! I hope you have tested the existing protocols with these changes. - Nilay On 2011-03-31 12:20:53, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- (Updated 2011-03-31 12:20:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/630/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/ --- (Updated 2011-03-31 14:26:33.755740) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/630/diff Testing (updated) --- So - just to add a note (this is not about testing). I had uploaded a patch, then realized that there was some dead code that I should also remove, so I uploaded a new patch. However, the head of my tree had changed, and that appears to have messed up my ability to update patches. So, two upshots: One, this newer patch gets rid of the some of the str.replace(*, ) code that was in place to auto-remove the *s from m_cache_entry and m_tbe, since now, those guys do not have *s by default. Two, don't change the head of your tree and have outstanding patches at the same time, if you think you want to update patches. Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/#review1066 --- Ship it! Lisa, the changes look fine to me. Just make sure that all the existing protocols compile properly. - Nilay On 2011-03-31 14:26:33, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/ --- (Updated 2011-03-31 14:26:33) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/630/diff Testing --- So - just to add a note (this is not about testing). I had uploaded a patch, then realized that there was some dead code that I should also remove, so I uploaded a new patch. However, the head of my tree had changed, and that appears to have messed up my ability to update patches. So, two upshots: One, this newer patch gets rid of the some of the str.replace(*, ) code that was in place to auto-remove the *s from m_cache_entry and m_tbe, since now, those guys do not have *s by default. Two, don't change the head of your tree and have outstanding patches at the same time, if you think you want to update patches. Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
On 2011-03-31 14:22:16, Nilay Vaish wrote: I hope you have tested the existing protocols with these changes. Yes - MOESI_[CMP_[directory|token]|hammer] all compile and run -l 1000 -n 4 on the Ruby Tester. Since no logic has changed (for all my Ruby changes), I believe it's sufficient testing, since the MSB in correctness is compilation. - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1065 --- On 2011-03-31 12:20:53, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- (Updated 2011-03-31 12:20:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: pass Packet-Req-contextId() to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/#review1068 --- Ship it! - Brad On 2011-03-31 12:16:27, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/ --- (Updated 2011-03-31 12:16:27) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: pass Packet-Req-contextId() to Ruby. It is useful for Ruby to understand from whence request packets came. This has all request packets going into Ruby pass the contextId value, if it exists. This supplants the old libruby proc_id value passed around in all the Messages, so I've also removed the unused unsigned proc_id; member generated by SLICC for all Message types. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf src/mem/ruby/system/Sequencer.cc d8587c913ccf src/mem/slicc/symbols/Type.py d8587c913ccf Diff: http://reviews.m5sim.org/r/623/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1069 --- src/mem/slicc/symbols/StateMachine.py http://reviews.m5sim.org/r/624/#comment1432 Do you also need to declare the contains_dma_sequencer flag here and set it to False? - Brad On 2011-03-31 12:20:53, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- (Updated 2011-03-31 12:20:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: have the rubytester pass contextId to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/#review1070 --- Ship it! - Brad On 2011-03-31 12:20:59, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/ --- (Updated 2011-03-31 12:20:59) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: have the rubytester pass contextId to Ruby. Diffs - src/cpu/testers/rubytest/Check.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/625/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
On 2011-03-31 11:11:03, Brad Beckmann wrote: src/mem/ruby/system/RubyPort.cc, line 321 http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321 This loop is probably the most complicated and important part of this patch. It might be easiest if we move this functionality into two different functions, one for reads and one for writes. The read scan just needs to ensure that at least one memory says that it has the address in Read_Only or ReadWrite state. We may also want to doublecheck that multiple memories say they have the address in ReadWrite state. The write scan is more complicated. If one memory says that it has the address in ReadWrite state, then I don't think it matters what state the other memories are in (except of course if another memory says it also has the address in ReadWrite), the write should succeed. Also if the write scans says that all copies are in Read_Only or Invalid/NotPresent state and no copies are Busy, the write should succeed. However, writes should fail if either no Read_Only or ReadWrite copies are found, or if a Busy copy is found and no ReadWrite copy is found. The latter situation will likely indicate the functional write is racing with a timing write. There is no easy, protocol-agnostic way to resolve such a race in the current infrastructure. Make sense? I think we should have the following cases for functional writes -- 1. Only read only copies -- write succeeds 2. One read write copy -- write succeeds 3. At least one busy -- write fails. 4. None of the above, then simply update the memory. Memory should also get updated in 1. as well. Brad, from your comment it seems that you expect that there can be multiple read-write copies simultaneously. Is this possible, or would this be a bug in the protocol? - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1054 --- On 2011-03-30 16:19:26, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-30 16:19:26) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py d54b7775a6b0 configs/ruby/Ruby.py d54b7775a6b0 src/mem/ruby/network/Network.cc d54b7775a6b0 src/mem/ruby/network/Network.py d54b7775a6b0 src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 src/mem/ruby/profiler/Profiler.py d54b7775a6b0 src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 src/mem/ruby/recorder/Tracer.py d54b7775a6b0 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py d54b7775a6b0 src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 src/mem/ruby/system/RubyPort.hh d54b7775a6b0 src/mem/ruby/system/RubyPort.cc d54b7775a6b0 src/mem/ruby/system/RubySystem.py d54b7775a6b0 src/mem/ruby/system/SConscript d54b7775a6b0 src/mem/ruby/system/Sequencer.py d54b7775a6b0 src/mem/ruby/system/System.hh d54b7775a6b0 src/mem/ruby/system/System.cc d54b7775a6b0 Diff: http://reviews.m5sim.org/r/611/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: Add new object called WireBuffer to mimic a Wire.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/#review1072 --- Ship it! Other than Nilay's comments, this looks good to me. - Brad On 2011-03-31 12:21:07, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/ --- (Updated 2011-03-31 12:21:07) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/SConscript d8587c913ccf src/mem/ruby/system/SConscript d8587c913ccf src/mem/ruby/system/WireBuffer.hh PRE-CREATION src/mem/ruby/system/WireBuffer.cc PRE-CREATION src/mem/ruby/system/WireBuffer.py PRE-CREATION src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/627/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
On 2011-03-31 14:22:16, Nilay Vaish wrote: I hope you have tested the existing protocols with these changes. Lisa Hsu wrote: Yes - MOESI_[CMP_[directory|token]|hammer] all compile and run -l 1000 -n 4 on the Ruby Tester. Since no logic has changed (for all my Ruby changes), I believe it's sufficient testing, since the MSB in correctness is compilation. That should be sufficient. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1065 --- On 2011-03-31 12:20:53, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- (Updated 2011-03-31 12:20:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Simplify SLICC and Entry/TBE handling.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/#review1074 --- Ship it! - Brad On 2011-03-31 14:26:33, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/630/ --- (Updated 2011-03-31 14:26:33) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Simplify SLICC and Entry/TBE handling. Before this changeset, all local variables of type Entry and TBE were considered to be pointers, but an immediate use of said variables would not be automatically deferenced in SLICC-generated code. Instead, deferences occurred when such variables were passed to functions, and were automatically dereferenced in the bodies of the functions (e.g. the implicitly passed cache_entry). This is a more general way to do it, which leaves in place the assumption that parameters to functions and local variables of type AbstractCacheEntry and TBE are always pointers, but instead of dereferencing to access member variables on a contextual basis, the dereferencing automatically occurs on a type basis at the moment a member is being accessed. So, now, things you can do that you couldn't before include: Entry foo := getCacheEntry(address); cache_entry.DataBlk := foo.DataBlk; or cache_entry.DataBlk := getCacheEntry(address).DataBlk; or even cache_entry.DataBlk := static_cast(Entry, pointer, cache.lookup(address)).DataBlk; Diffs - src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf src/mem/slicc/ast/FormalParamAST.py d8587c913ccf src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf src/mem/slicc/ast/MemberExprAST.py d8587c913ccf Diff: http://reviews.m5sim.org/r/630/diff Testing --- So - just to add a note (this is not about testing). I had uploaded a patch, then realized that there was some dead code that I should also remove, so I uploaded a new patch. However, the head of my tree had changed, and that appears to have messed up my ability to update patches. So, two upshots: One, this newer patch gets rid of the some of the str.replace(*, ) code that was in place to auto-remove the *s from m_cache_entry and m_tbe, since now, those guys do not have *s by default. Two, don't change the head of your tree and have outstanding patches at the same time, if you think you want to update patches. Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
On 2011-03-31 15:58:14, Brad Beckmann wrote: src/mem/slicc/symbols/StateMachine.py, line 477 http://reviews.m5sim.org/r/624/diff/1/?file=11400#file11400line477 Do you also need to declare the contains_dma_sequencer flag here and set it to False? Brad, great catch - since contains_sequencer is no longer used at all, it should be s/contains_sequencer/contains_dma_sequencer/g. You pointing this out makes me realize that I have not compiled against FS at all, and I was using regression quick tests as my measuring stick. I'll add that fix and make sure the protocols compile under FS as well. This should be the only thing out of all the patches that has anything to do with FS|SE distinction though. - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1069 --- On 2011-03-31 12:20:53, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/ --- (Updated 2011-03-31 12:20:53) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: enable multiple sequencers in one controller. Diffs - src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/624/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add new object called WireBuffer to mimic a Wire.
On 2011-03-31 14:19:44, Nilay Vaish wrote: src/mem/ruby/system/WireBuffer.py, line 31 http://reviews.m5sim.org/r/627/diff/1/?file=11408#file11408line31 Do we need this commented piece of code? Thanks for catching these. I thought I cleaned up that stuff, but I obviously missed some. Thanks! - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/#review1063 --- On 2011-03-31 12:21:07, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/ --- (Updated 2011-03-31 12:21:07) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/SConscript d8587c913ccf src/mem/ruby/system/SConscript d8587c913ccf src/mem/ruby/system/WireBuffer.hh PRE-CREATION src/mem/ruby/system/WireBuffer.cc PRE-CREATION src/mem/ruby/system/WireBuffer.py PRE-CREATION src/mem/slicc/symbols/StateMachine.py d8587c913ccf Diff: http://reviews.m5sim.org/r/627/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1077 --- This is more of a question, then a suggestion. Is there a way to use allocateVoid() a wrapper around allocate() rather than have to duplicate code? What happens if you cast the return pointer to void? Does that suppresss the error? Maybe there is a way to set some attribute on the variable that the compiler can understand. I have no idea if that is actually possible and if any solution would be portable across compiler generations. I'm just curious if there was some way to avoid the code duplication. - Brad On 2011-03-31 12:21:22, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/ --- (Updated 2011-03-31 12:21:22) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/system/CacheMemory.hh d8587c913ccf src/mem/ruby/system/CacheMemory.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/629/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
On 2011-03-31 11:11:03, Brad Beckmann wrote: src/mem/ruby/system/RubyPort.cc, line 321 http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321 This loop is probably the most complicated and important part of this patch. It might be easiest if we move this functionality into two different functions, one for reads and one for writes. The read scan just needs to ensure that at least one memory says that it has the address in Read_Only or ReadWrite state. We may also want to doublecheck that multiple memories say they have the address in ReadWrite state. The write scan is more complicated. If one memory says that it has the address in ReadWrite state, then I don't think it matters what state the other memories are in (except of course if another memory says it also has the address in ReadWrite), the write should succeed. Also if the write scans says that all copies are in Read_Only or Invalid/NotPresent state and no copies are Busy, the write should succeed. However, writes should fail if either no Read_Only or ReadWrite copies are found, or if a Busy copy is found and no ReadWrite copy is found. The latter situation will likely indicate the functional write is racing with a timing write. There is no easy, protocol-agnostic way to resolve such a race in the current infrastructure. Make sense? Nilay Vaish wrote: I think we should have the following cases for functional writes -- 1. Only read only copies -- write succeeds 2. One read write copy -- write succeeds 3. At least one busy -- write fails. 4. None of the above, then simply update the memory. Memory should also get updated in 1. as well. Brad, from your comment it seems that you expect that there can be multiple read-write copies simultaneously. Is this possible, or would this be a bug in the protocol? You are absolutely right, that would be an error in the protocol. It just seems that since we are scanning the state of the address in the system, we might as well double check that at most one ReadWrite copy exists. I completely agree with your first two cases. However, I think the third case is slightly too restrictive. Just because one memory has the address as Busy, doesn't necessarily mean that we cannot update the block. If another memory has the block in read-write state, we can be certain that that particular copy is not only still valid, but has also yet to relinquish exclusive ownership. Therefore a function write to that block can succeed. Meanwhile, if we find a Busy block and just Read_Only block(s), than other valid copies may exist somewhere in the system and thus the functional write likely won't succeed. I'm confused by your fourth case. Isn't Ruby memory (a.k.a. DirectoryMemory) just another AbstractMemory object and thus just another memory in the list of memories? My hope was that we would treat CacheMemory and DirectoryMemory the same when doing functional accesses. Am I missing something? - Brad --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1054 --- On 2011-03-30 16:19:26, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-30 16:19:26) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py d54b7775a6b0 configs/ruby/Ruby.py d54b7775a6b0 src/mem/ruby/network/Network.cc d54b7775a6b0 src/mem/ruby/network/Network.py d54b7775a6b0 src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 src/mem/ruby/profiler/Profiler.py d54b7775a6b0 src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 src/mem/ruby/recorder/Tracer.py d54b7775a6b0 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py d54b7775a6b0 src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 src/mem/ruby/system/RubyPort.hh d54b7775a6b0 src/mem/ruby/system/RubyPort.cc d54b7775a6b0 src/mem/ruby/system/RubySystem.py d54b7775a6b0 src/mem/ruby/system/SConscript d54b7775a6b0 src/mem/ruby/system/Sequencer.py d54b7775a6b0 src/mem/ruby/system/System.hh d54b7775a6b0
[m5-dev] changeset in m5: Ruby: pass Packet-Req-contextId() to Ruby.
changeset 20dbef14192d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=20dbef14192d
description:
Ruby: pass Packet-Req-contextId() to Ruby.
It is useful for Ruby to understand from whence request packets came.
This has all request packets going into Ruby pass the contextId value,
if
it exists. This supplants the old libruby proc_id value passed around
in
all the Messages, so I've also removed the unused unsigned proc_id;
member
generated by SLICC for all Message types.
diffstat:
src/mem/protocol/RubySlicc_Types.sm | 1 +
src/mem/ruby/slicc_interface/RubyRequest.hh | 4 ++--
src/mem/ruby/system/Sequencer.cc| 4 +++-
src/mem/slicc/symbols/Type.py | 12
4 files changed, 6 insertions(+), 15 deletions(-)
diffs (93 lines):
diff -r 99428f716e7b -r 20dbef14192d src/mem/protocol/RubySlicc_Types.sm
--- a/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 12:20:16 2011 -0700
+++ b/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 17:17:47 2011 -0700
@@ -117,6 +117,7 @@
RubyAccessMode AccessMode, desc=user/supervisor access type;
int Size, desc=size in bytes of access;
PrefetchBit Prefetch, desc=Is this a prefetch request;
+ int contextId, desc=this goes away but must be replace with
Nilay;
}
external_type(AbstractEntry, primitive=yes);
diff -r 99428f716e7b -r 20dbef14192d src/mem/ruby/slicc_interface/RubyRequest.hh
--- a/src/mem/ruby/slicc_interface/RubyRequest.hh Thu Mar 31 12:20:16
2011 -0700
+++ b/src/mem/ruby/slicc_interface/RubyRequest.hh Thu Mar 31 17:17:47
2011 -0700
@@ -52,7 +52,7 @@
PrefetchBit m_Prefetch;
uint8_t* data;
PacketPtr pkt;
-unsigned proc_id;
+unsigned m_contextId;
RubyRequest() {}
RubyRequest(uint64_t _paddr, uint8_t* _data, int _len, uint64_t _pc,
@@ -67,7 +67,7 @@
m_Prefetch(_pb),
data(_data),
pkt(_pkt),
- proc_id(_proc_id)
+ m_contextId(_proc_id)
{
m_LineAddress = m_PhysicalAddress;
m_LineAddress.makeLineAddress();
diff -r 99428f716e7b -r 20dbef14192d src/mem/ruby/system/Sequencer.cc
--- a/src/mem/ruby/system/Sequencer.cc Thu Mar 31 12:20:16 2011 -0700
+++ b/src/mem/ruby/system/Sequencer.cc Thu Mar 31 17:17:47 2011 -0700
@@ -671,11 +671,13 @@
Address line_addr(request.m_PhysicalAddress);
line_addr.makeLineAddress();
+int proc_id = request.pkt-req-hasContextId() ?
+request.pkt-req-contextId() : -1;
RubyRequest *msg = new RubyRequest(request.m_PhysicalAddress.getAddress(),
request.data, request.m_Size,
request.m_ProgramCounter.getAddress(),
ctype, amtype, request.pkt,
- PrefetchBit_No, request.proc_id);
+ PrefetchBit_No, proc_id);
DPRINTFR(ProtocolTrace, %7s %3s %10s%20s %6s%-6s %s %s\n,
g_eventQueue_ptr-getTime(), m_version, Seq, Begin, , ,
diff -r 99428f716e7b -r 20dbef14192d src/mem/slicc/symbols/Type.py
--- a/src/mem/slicc/symbols/Type.py Thu Mar 31 12:20:16 2011 -0700
+++ b/src/mem/slicc/symbols/Type.py Thu Mar 31 17:17:47 2011 -0700
@@ -261,9 +261,6 @@
for dm in self.data_members.values():
code('m_${{dm.ident}} = other.m_${{dm.ident}};')
-if self.isMessage:
-code('proc_id = other.proc_id;')
-
code.dedent()
code('}')
@@ -272,9 +269,6 @@
params = [ 'const %s local_%s' % (dm.type.c_ident, dm.ident) \
for dm in self.data_members.itervalues() ]
-if self.isMessage:
-params.append('const unsigned local_proc_id')
-
params = ', '.join(params)
code('${{self.c_ident}}($params)')
@@ -289,9 +283,6 @@
if nextLineCallHack in dm:
code('m_${{dm.ident}}${{dm[nextLineCallHack]}};')
-if self.isMessage:
-code('proc_id = local_proc_id;')
-
code.dedent()
code('}')
@@ -377,9 +368,6 @@
code('$const${{dm.type.c_ident}} m_${{dm.ident}}$init;')
-if self.isMessage:
-code('unsigned proc_id;')
-
code.dedent()
code('};')
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: enable multiple sequencers in one control...
changeset d5ad24eb015f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d5ad24eb015f
description:
Ruby: enable multiple sequencers in one controller.
diffstat:
src/mem/slicc/symbols/StateMachine.py | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diffs (54 lines):
diff -r 20dbef14192d -r d5ad24eb015f src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Thu Mar 31 17:17:47 2011 -0700
+++ b/src/mem/slicc/symbols/StateMachine.py Thu Mar 31 17:17:49 2011 -0700
@@ -30,6 +30,7 @@
from slicc.symbols.Symbol import Symbol
from slicc.symbols.Var import Var
import slicc.generate.html as html
+import re
python_class_map = {int: Int,
std::string: String,
@@ -473,10 +474,13 @@
# params include a sequencer. This information will be used later for
# contecting the sequencer back to the L1 cache controller.
#
-contains_sequencer = False
+contains_dma_sequencer = False
+sequencers = []
for param in self.config_parameters:
-if param.name == sequencer or param.name == dma_sequencer:
-contains_sequencer = True
+if param.name == dma_sequencer:
+contains_dma_sequencer = True
+elif re.compile(sequencer).search(param.name):
+sequencers.append(param.name)
if param.pointer:
code('m_${{param.name}}_ptr = p-${{param.name}};')
else:
@@ -487,19 +491,20 @@
# includes passing the sequencer a pointer to the controller.
#
if self.ident == L1Cache:
-if not contains_sequencer:
+if not sequencers:
self.error(The L1Cache controller must include the sequencer
\
configuration parameter)
-code('''
-m_sequencer_ptr-setController(this);
-''')
+for seq in sequencers:
+code('''
+m_${{seq}}_ptr-setController(this);
+''')
#
# For the DMA controller, pass the sequencer a pointer to the
# controller.
#
if self.ident == DMA:
-if not contains_sequencer:
+if not contains_dma_sequencer:
self.error(The DMA controller must include the sequencer \
configuration parameter)
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: have the rubytester pass contextId to Ruby.
changeset 8c68155aac00 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=8c68155aac00 description: Ruby: have the rubytester pass contextId to Ruby. diffstat: src/cpu/testers/rubytest/Check.cc | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diffs (27 lines): diff -r d5ad24eb015f -r 8c68155aac00 src/cpu/testers/rubytest/Check.cc --- a/src/cpu/testers/rubytest/Check.cc Thu Mar 31 17:17:49 2011 -0700 +++ b/src/cpu/testers/rubytest/Check.cc Thu Mar 31 17:17:51 2011 -0700 @@ -104,6 +104,7 @@ // Prefetches are assumed to be 0 sized Request *req = new Request(m_address.getAddress(), 0, flags, curTick(), m_pc.getAddress()); +req-setThreadContext(index, 0); PacketPtr pkt = new Packet(req, cmd, port-idx); @@ -177,6 +178,7 @@ Request *req = new Request(writeAddr.getAddress(), 1, flags, curTick(), m_pc.getAddress()); +req-setThreadContext(index, 0); Packet::Command cmd; // 1 out of 8 chance, issue an atomic rather than a write @@ -242,6 +244,7 @@ Request *req = new Request(m_address.getAddress(), CHECK_SIZE, flags, curTick(), m_pc.getAddress()); +req-setThreadContext(index, 0); PacketPtr pkt = new Packet(req, MemCmd::ReadReq, port-idx); uint8_t* dataArray = new uint8_t[CHECK_SIZE]; pkt-dataDynamicArray(dataArray); ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Add new object called WireBuffer to mimic...
changeset 777459f7c61f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=777459f7c61f
description:
Ruby: Add new object called WireBuffer to mimic a Wire.
This is a substitute for MessageBuffers between controllers where you
don't
want messages to actually go through the Network, because
requests/responses can
always get reordered wrt to one another (even if you turn off
Randomization and turn on Ordered)
because you are, after all, going through a network with contention.
For systems where you model
multiple controllers that are very tightly coupled and do not actually
go through a network,
it is a pain to have to write a coherence protocol to account for mixed
up request/response orderings
despite the fact that it's completely unrealistic. This is *not* meant
as a substitute for real
MessageBuffers when messages do in fact go over a network.
diffstat:
src/mem/protocol/RubySlicc_Types.sm |4 +
src/mem/ruby/SConscript |1 +
src/mem/ruby/system/SConscript|2 +
src/mem/ruby/system/WireBuffer.cc | 171 ++
src/mem/ruby/system/WireBuffer.hh | 108 +
src/mem/ruby/system/WireBuffer.py | 35 ++
src/mem/slicc/symbols/StateMachine.py |1 +
7 files changed, 322 insertions(+), 0 deletions(-)
diffs (truncated from 381 to 300 lines):
diff -r 8c68155aac00 -r 777459f7c61f src/mem/protocol/RubySlicc_Types.sm
--- a/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 17:17:51 2011 -0700
+++ b/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 17:17:57 2011 -0700
@@ -146,6 +146,10 @@
void setMRU(Address);
}
+structure (WireBuffer, inport=yes, outport=yes, external = yes) {
+
+}
+
structure (MemoryControl, inport=yes, outport=yes, external = yes) {
}
diff -r 8c68155aac00 -r 777459f7c61f src/mem/ruby/SConscript
--- a/src/mem/ruby/SConscript Thu Mar 31 17:17:51 2011 -0700
+++ b/src/mem/ruby/SConscript Thu Mar 31 17:17:57 2011 -0700
@@ -107,6 +107,7 @@
MakeInclude('system/DirectoryMemory.hh')
MakeInclude('system/MachineID.hh')
MakeInclude('system/MemoryControl.hh')
+MakeInclude('system/WireBuffer.hh')
MakeInclude('system/NodeID.hh')
MakeInclude('system/PerfectCacheMemory.hh')
MakeInclude('system/PersistentTable.hh')
diff -r 8c68155aac00 -r 777459f7c61f src/mem/ruby/system/SConscript
--- a/src/mem/ruby/system/SConscriptThu Mar 31 17:17:51 2011 -0700
+++ b/src/mem/ruby/system/SConscriptThu Mar 31 17:17:57 2011 -0700
@@ -37,6 +37,7 @@
SimObject('Sequencer.py')
SimObject('DirectoryMemory.py')
SimObject('MemoryControl.py')
+SimObject('WireBuffer.py')
SimObject('RubySystem.py')
Source('DMASequencer.cc')
@@ -44,6 +45,7 @@
Source('SparseMemory.cc')
Source('CacheMemory.cc')
Source('MemoryControl.cc')
+Source('WireBuffer.cc')
Source('MemoryNode.cc')
Source('PersistentTable.cc')
Source('RubyPort.cc')
diff -r 8c68155aac00 -r 777459f7c61f src/mem/ruby/system/WireBuffer.cc
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/mem/ruby/system/WireBuffer.cc Thu Mar 31 17:17:57 2011 -0700
@@ -0,0 +1,171 @@
+/*
+ * Copyright (c) 2010 Advanced Micro Devices, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Author: Lisa Hsu
+ *
+ */
+
+#include algorithm
+#include functional
+
+#include base/cprintf.hh
+#include base/stl_helpers.hh
+#include mem/ruby/system/WireBuffer.hh
+
+using namespace std;
+
+class Consumer;
+
+
+//
[m5-dev] changeset in m5: Ruby: Simplify SLICC and Entry/TBE handling.
changeset be38f7b6ad9e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=be38f7b6ad9e
description:
Ruby: Simplify SLICC and Entry/TBE handling.
Before this changeset, all local variables of type Entry and TBE were
considered
to be pointers, but an immediate use of said variables would not be
automatically
deferenced in SLICC-generated code. Instead, deferences occurred when
such
variables were passed to functions, and were automatically dereferenced
in
the bodies of the functions (e.g. the implicitly passed cache_entry).
This is a more general way to do it, which leaves in place the
assumption that parameters to functions and local variables of type
AbstractCacheEntry
and TBE are always pointers, but instead of dereferencing to access
member variables
on a contextual basis, the dereferencing automatically occurs on a type
basis at the
moment a member is being accessed. So, now, things you can do that you
couldn't before
include:
Entry foo := getCacheEntry(address);
cache_entry.DataBlk := foo.DataBlk;
or
cache_entry.DataBlk := getCacheEntry(address).DataBlk;
or even
cache_entry.DataBlk := static_cast(Entry, pointer,
cache.lookup(address)).DataBlk;
diffstat:
src/mem/slicc/ast/ActionDeclAST.py | 4 ++--
src/mem/slicc/ast/FormalParamAST.py| 13 -
src/mem/slicc/ast/FuncCallExprAST.py | 22 ++
src/mem/slicc/ast/IsValidPtrExprAST.py | 5 ++---
src/mem/slicc/ast/MemberExprAST.py | 7 ++-
5 files changed, 20 insertions(+), 31 deletions(-)
diffs (109 lines):
diff -r 777459f7c61f -r be38f7b6ad9e src/mem/slicc/ast/ActionDeclAST.py
--- a/src/mem/slicc/ast/ActionDeclAST.pyThu Mar 31 17:17:57 2011 -0700
+++ b/src/mem/slicc/ast/ActionDeclAST.pyThu Mar 31 17:18:00 2011 -0700
@@ -59,12 +59,12 @@
if machine.TBEType != None:
var = Var(self.symtab, tbe, self.location, machine.TBEType,
- (*m_tbe_ptr), self.pairs)
+ m_tbe_ptr, self.pairs)
self.symtab.newSymbol(var)
if machine.EntryType != None:
var = Var(self.symtab, cache_entry, self.location,
- machine.EntryType, (*m_cache_entry_ptr),
self.pairs)
+ machine.EntryType, m_cache_entry_ptr, self.pairs)
self.symtab.newSymbol(var)
# Do not allows returns in actions
diff -r 777459f7c61f -r be38f7b6ad9e src/mem/slicc/ast/FormalParamAST.py
--- a/src/mem/slicc/ast/FormalParamAST.py Thu Mar 31 17:17:57 2011 -0700
+++ b/src/mem/slicc/ast/FormalParamAST.py Thu Mar 31 17:18:00 2011 -0700
@@ -48,17 +48,12 @@
param = param_%s % self.ident
# Add to symbol table
+v = Var(self.symtab, self.ident, self.location, type, param,
+self.pairs)
+self.symtab.newSymbol(v)
if self.pointer or str(type) == TBE or (
interface in type and type[interface] == AbstractCacheEntry):
-v = Var(self.symtab, self.ident, self.location, type,
-(*%s) % param, self.pairs)
-self.symtab.newSymbol(v)
return type, %s* %s % (type.c_ident, param)
-
else:
-v = Var(self.symtab, self.ident, self.location, type, param,
-self.pairs)
-self.symtab.newSymbol(v)
-
-return type, %s %s % (type.c_ident, param)
+return type, %s %s % (type.c_ident, param)
diff -r 777459f7c61f -r be38f7b6ad9e src/mem/slicc/ast/FuncCallExprAST.py
--- a/src/mem/slicc/ast/FuncCallExprAST.py Thu Mar 31 17:17:57 2011 -0700
+++ b/src/mem/slicc/ast/FuncCallExprAST.py Thu Mar 31 17:18:00 2011 -0700
@@ -217,22 +217,12 @@
first_param = True
for (param_code, type) in zip(cvec, type_vec):
- if str(type) == TBE or (interface in type and
-type[interface] == AbstractCacheEntry):
-
- if first_param:
- params = str(param_code).replace('*','')
- first_param = False
- else:
- params += ', '
- params += str(param_code).replace('*','');
- else:
- if first_param:
- params = str(param_code)
- first_param = False
- else:
- params += ', '
- params += str(param_code);
+if first_param:
+params = str(param_code)
+first_param = False
+else:
+params += ', '
+params += str(param_code);
fix = code.nofix()
Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
On 2011-03-31 16:15:29, Brad Beckmann wrote: This is more of a question, then a suggestion. Is there a way to use allocateVoid() a wrapper around allocate() rather than have to duplicate code? What happens if you cast the return pointer to void? Does that suppresss the error? Maybe there is a way to set some attribute on the variable that the compiler can understand. I have no idea if that is actually possible and if any solution would be portable across compiler generations. I'm just curious if there was some way to avoid the code duplication. Brad, I agree it's kind of ugly and I've never been a fan of code duplication. (Which reminds me - why do we need two copies of lookup(), one const and one not in CacheMemory?) I'll try the void * return suggestion, though I wouldn't hold my breath. I'm open to other suggestions as well, if anyone has any. I didn't get too creative here. - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1077 --- On 2011-03-31 12:21:22, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/ --- (Updated 2011-03-31 12:21:22) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/system/CacheMemory.hh d8587c913ccf src/mem/ruby/system/CacheMemory.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/629/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
On 2011-03-31 16:15:29, Brad Beckmann wrote: This is more of a question, then a suggestion. Is there a way to use allocateVoid() a wrapper around allocate() rather than have to duplicate code? What happens if you cast the return pointer to void? Does that suppresss the error? Maybe there is a way to set some attribute on the variable that the compiler can understand. I have no idea if that is actually possible and if any solution would be portable across compiler generations. I'm just curious if there was some way to avoid the code duplication. Lisa Hsu wrote: Brad, I agree it's kind of ugly and I've never been a fan of code duplication. (Which reminds me - why do we need two copies of lookup(), one const and one not in CacheMemory?) I'll try the void * return suggestion, though I wouldn't hold my breath. I'm open to other suggestions as well, if anyone has any. I didn't get too creative here. Ok, I think I must have been brain farting. This patch was the least of my worries, I was more concerned about the ruby-local one, so clearly I didn't even spend an iota of time thinking about this. I've wrapped allocate() appropriately with no duplication and it works. Will check in that version. Must be quitting time :). - Lisa --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1077 --- On 2011-03-31 12:21:22, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/ --- (Updated 2011-03-31 12:21:22) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. Diffs - src/mem/protocol/RubySlicc_Types.sm d8587c913ccf src/mem/ruby/system/CacheMemory.hh d8587c913ccf src/mem/ruby/system/CacheMemory.cc d8587c913ccf Diff: http://reviews.m5sim.org/r/629/diff Testing --- Thanks, Lisa ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: CacheMemory: add allocateVoid() that is == allo...
changeset c7302d55d644 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c7302d55d644
description:
CacheMemory: add allocateVoid() that is == allocate() but no return
value.
This function duplicates the functionality of allocate() exactly,
except that it does not return
a return value. In protocols where you just want to allocate a block
but do not want that block to be your implicitly passed cache_entry,
use this function.
Otherwise, SLICC will complain if you do not consume the pointer
returned by allocate(),
and if you do a dummy assignment Entry foo := cache.allocate(address),
the C++
compiler will complain of an unused variable. This is kind of a hack
to get around
those issues, but suggestions welcome.
diffstat:
src/mem/protocol/RubySlicc_Types.sm | 1 +
src/mem/ruby/system/CacheMemory.hh | 4
src/mem/ruby/system/WireBuffer.hh | 3 +--
src/mem/ruby/system/WireBuffer.py | 1 -
4 files changed, 6 insertions(+), 3 deletions(-)
diffs (56 lines):
diff -r be38f7b6ad9e -r c7302d55d644 src/mem/protocol/RubySlicc_Types.sm
--- a/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 17:18:00 2011 -0700
+++ b/src/mem/protocol/RubySlicc_Types.sm Thu Mar 31 18:20:12 2011 -0700
@@ -134,6 +134,7 @@
bool cacheAvail(Address);
Address cacheProbe(Address);
AbstractCacheEntry allocate(Address, AbstractCacheEntry);
+ void allocateVoid(Address, AbstractCacheEntry);
void deallocate(Address);
AbstractCacheEntry lookup(Address);
bool isTagPresent(Address);
diff -r be38f7b6ad9e -r c7302d55d644 src/mem/ruby/system/CacheMemory.hh
--- a/src/mem/ruby/system/CacheMemory.hhThu Mar 31 17:18:00 2011 -0700
+++ b/src/mem/ruby/system/CacheMemory.hhThu Mar 31 18:20:12 2011 -0700
@@ -83,6 +83,10 @@
// find an unused entry and sets the tag appropriate for the address
AbstractCacheEntry* allocate(const Address address, AbstractCacheEntry*
new_entry);
+void allocateVoid(const Address address, AbstractCacheEntry* new_entry)
+{
+allocate(address, new_entry);
+}
// Explicitly free up this address
void deallocate(const Address address);
diff -r be38f7b6ad9e -r c7302d55d644 src/mem/ruby/system/WireBuffer.hh
--- a/src/mem/ruby/system/WireBuffer.hh Thu Mar 31 17:18:00 2011 -0700
+++ b/src/mem/ruby/system/WireBuffer.hh Thu Mar 31 18:20:12 2011 -0700
@@ -54,7 +54,7 @@
/
class Consumer;
-class Message; // I added this and removed Message.hh
+class Message;
class WireBuffer : public SimObject
{
@@ -88,7 +88,6 @@
void clearStats() const;
void printStats(std::ostream out) const;
-//int m_dummy;
uint64_t m_msg_counter;
private:
diff -r be38f7b6ad9e -r c7302d55d644 src/mem/ruby/system/WireBuffer.py
--- a/src/mem/ruby/system/WireBuffer.py Thu Mar 31 17:18:00 2011 -0700
+++ b/src/mem/ruby/system/WireBuffer.py Thu Mar 31 18:20:12 2011 -0700
@@ -28,7 +28,6 @@
from m5.params import *
from m5.SimObject import SimObject
-#from Controller import RubyController
class RubyWireBuffer(SimObject):
type = 'RubyWireBuffer'
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: CacheMemory: add allocateVoid() that is == allo...
Lisa, should not compiler yell in this case as well? Nilay On Thu, March 31, 2011 8:22 pm, Lisa Hsu wrote: changeset c7302d55d644 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c7302d55d644 description: CacheMemory: add allocateVoid() that is == allocate() but no return value. This function duplicates the functionality of allocate() exactly, except that it does not return a return value. In protocols where you just want to allocate a block but do not want that block to be your implicitly passed cache_entry, use this function. Otherwise, SLICC will complain if you do not consume the pointer returned by allocate(), and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ compiler will complain of an unused variable. This is kind of a hack to get around those issues, but suggestions welcome. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-31 20:44:17.499794) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - configs/ruby/MESI_CMP_directory.py c7302d55d644 configs/ruby/Ruby.py c7302d55d644 src/mem/ruby/network/Network.cc c7302d55d644 src/mem/ruby/network/Network.py c7302d55d644 src/mem/ruby/profiler/Profiler.cc c7302d55d644 src/mem/ruby/profiler/Profiler.py c7302d55d644 src/mem/ruby/recorder/Tracer.cc c7302d55d644 src/mem/ruby/recorder/Tracer.py c7302d55d644 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py c7302d55d644 src/mem/ruby/system/CacheMemory.hh c7302d55d644 src/mem/ruby/system/CacheMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.py c7302d55d644 src/mem/ruby/system/RubyPort.hh c7302d55d644 src/mem/ruby/system/RubyPort.cc c7302d55d644 src/mem/ruby/system/RubySystem.py c7302d55d644 src/mem/ruby/system/SConscript c7302d55d644 src/mem/ruby/system/Sequencer.cc c7302d55d644 src/mem/ruby/system/Sequencer.py c7302d55d644 src/mem/ruby/system/System.hh c7302d55d644 src/mem/ruby/system/System.cc c7302d55d644 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: X86: fnstsw: Another patch from Vince Weaver
It might be ok, but I've been busy and forgot to look at it. Please give me a few more days. Gabe Quoting Lisa Hsu h...@eecs.umich.edu: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/594/#review1056 --- Since there have been no objections, I'm going to commit this. - Lisa On 2011-03-17 16:07:24, Lisa Hsu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/594/ --- (Updated 2011-03-17 16:07:24) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- X86: fnstsw: Another patch from Vince Weaver Diffs - src/arch/x86/isa/decoder/x87.isa 2e269d6fb3e6 src/arch/x86/isa/insts/x87/control/save_x87_status_word.py 2e269d6fb3e6 src/arch/x86/isa/operands.isa 2e269d6fb3e6 src/arch/x86/regs/misc.hh 2e269d6fb3e6 Diff: http://reviews.m5sim.org/r/594/diff Testing --- Thanks, Lisa ___ 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: Add new object called WireBuffer to mimic a Wire.
Looks like Nilay is getting used to our style :) On Thu, Mar 31, 2011 at 2:19 PM, Nilay Vaish ni...@cs.wisc.edu wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/ src/mem/ruby/system/WireBuffer.hhhttp://reviews.m5sim.org/r/627/diff/1/?file=11406#file11406line57 (Diff revision 1) class Consumer; 57 class Message; // I added this and removed Message.hh Remove the comment. src/mem/ruby/system/WireBuffer.hhhttp://reviews.m5sim.org/r/627/diff/1/?file=11406#file11406line91 (Diff revision 1) class Consumer; 91 //int m_dummy; Remove this line as well. src/mem/ruby/system/WireBuffer.pyhttp://reviews.m5sim.org/r/627/diff/1/?file=11408#file11408line31 (Diff revision 1) 31 #from Controller import RubyController Do we need this commented piece of code? - Nilay On March 31st, 2011, 12:21 p.m., Lisa Hsu wrote: Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. By Lisa Hsu. *Updated 2011-03-31 12:21:07* Description Ruby: Add new object called WireBuffer to mimic a Wire. This is a substitute for MessageBuffers between controllers where you don't want messages to actually go through the Network, because requests/responses can always get reordered wrt to one another (even if you turn off Randomization and turn on Ordered) because you are, after all, going through a network with contention. For systems where you model multiple controllers that are very tightly coupled and do not actually go through a network, it is a pain to have to write a coherence protocol to account for mixed up request/response orderings despite the fact that it's completely unrealistic. This is *not* meant as a substitute for real MessageBuffers when messages do in fact go over a network. Diffs - src/mem/protocol/RubySlicc_Types.sm (d8587c913ccf) - src/mem/ruby/SConscript (d8587c913ccf) - src/mem/ruby/system/SConscript (d8587c913ccf) - src/mem/ruby/system/WireBuffer.hh (PRE-CREATION) - src/mem/ruby/system/WireBuffer.cc (PRE-CREATION) - src/mem/ruby/system/WireBuffer.py (PRE-CREATION) - src/mem/slicc/symbols/StateMachine.py (d8587c913ccf) View Diff http://reviews.m5sim.org/r/627/diff/ ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- This looks great, I just have a few minor suggestions below. It seems like the next step is to figure out how to deal with functional accesses not succeeding in the CPUs and devices. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1438 Please add comments to this function explaining what is going on here. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1439 It seems that the ro and rw counter checks should happen here, before doing any functional accesses. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1440 Try to avoid the duplicate code between here... src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1441 ...and here. src/mem/ruby/system/RubyPort.cc http://reviews.m5sim.org/r/611/#comment1442 Are functional packets put on the stack or the heap? I seem to remember the former, but I could be wrong. - Brad On 2011-03-31 20:44:17, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-31 20:44:17) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py c7302d55d644 configs/ruby/Ruby.py c7302d55d644 src/mem/ruby/network/Network.cc c7302d55d644 src/mem/ruby/network/Network.py c7302d55d644 src/mem/ruby/profiler/Profiler.cc c7302d55d644 src/mem/ruby/profiler/Profiler.py c7302d55d644 src/mem/ruby/recorder/Tracer.cc c7302d55d644 src/mem/ruby/recorder/Tracer.py c7302d55d644 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py c7302d55d644 src/mem/ruby/system/CacheMemory.hh c7302d55d644 src/mem/ruby/system/CacheMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.py c7302d55d644 src/mem/ruby/system/RubyPort.hh c7302d55d644 src/mem/ruby/system/RubyPort.cc c7302d55d644 src/mem/ruby/system/RubySystem.py c7302d55d644 src/mem/ruby/system/SConscript c7302d55d644 src/mem/ruby/system/Sequencer.cc c7302d55d644 src/mem/ruby/system/Sequencer.py c7302d55d644 src/mem/ruby/system/System.hh c7302d55d644 src/mem/ruby/system/System.cc c7302d55d644 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
