[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_token/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_FS/params/RubyDebug.hh' not found, needed by target `build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/MIPS_SE/params/RubyDebug.hh' not found, needed by target `build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/POWER_SE/params/RubyDebug.hh' not found, needed by target `build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/SPARC_SE/params/RubyDebug.hh' not found, needed by target `build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/X86_SE/params/RubyDebug.hh' not found, needed by target `build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_SE/params/RubyDebug.hh' not found, needed by target `build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_FS/params/RubyDebug.hh' not found, needed by target `build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc'. See /z/m5/regression/regress-2011-01-11-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I initially thought this was your RubyDebug.hh change, Nate, but I don't see RubyDebug in the repository anywhere now. In the past I've run into problems where left over files make a build break until you wipe it out and rebuild, specifically having to do with the python stuff. I suspect if you delete these build directories and rerun these might pass, but you might want to look them over to see why they need to be cleared out to work. Maybe something is including all the files in a particular directory, and even though scons isn't building them any more they're still getting picked up and folded in? Gabe Cron Daemon wrote: scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_token/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_FS/params/RubyDebug.hh' not found, needed by target `build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/MIPS_SE/params/RubyDebug.hh' not found, needed by target `build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/POWER_SE/params/RubyDebug.hh' not found, needed by target `build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/SPARC_SE/params/RubyDebug.hh' not found, needed by target `build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/X86_SE/params/RubyDebug.hh' not found, needed by target `build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_SE/params/RubyDebug.hh' not found, needed by target `build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_FS/params/RubyDebug.hh' not found, needed by target `build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc'. See /z/m5/regression/regress-2011-01-11-03:00:01 for details. ___ 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] Cron m5test@zizzer /z/m5/regression/do-regression quick
I also received this error after I pulled in Nate's changeset. Removing the build directory fixed the problem for me. Nilay On Tue, January 11, 2011 4:35 am, Gabe Black wrote: I initially thought this was your RubyDebug.hh change, Nate, but I don't see RubyDebug in the repository anywhere now. In the past I've run into problems where left over files make a build break until you wipe it out and rebuild, specifically having to do with the python stuff. I suspect if you delete these build directories and rerun these might pass, but you might want to look them over to see why they need to be cleared out to work. Maybe something is including all the files in a particular directory, and even though scons isn't building them any more they're still getting picked up and folded in? Gabe Cron Daemon wrote: scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_hammer/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_directory/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_directory/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_SE_MOESI_CMP_token/params/RubyDebug.hh' not found, needed by target `build/ALPHA_SE_MOESI_CMP_token/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ALPHA_FS/params/RubyDebug.hh' not found, needed by target `build/ALPHA_FS/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/MIPS_SE/params/RubyDebug.hh' not found, needed by target `build/MIPS_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/POWER_SE/params/RubyDebug.hh' not found, needed by target `build/POWER_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/SPARC_SE/params/RubyDebug.hh' not found, needed by target `build/SPARC_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/X86_SE/params/RubyDebug.hh' not found, needed by target `build/X86_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_SE/params/RubyDebug.hh' not found, needed by target `build/ARM_SE/python/m5/internal/param_RubySystem_wrap.cc'. scons: *** Implicit dependency `build/ARM_FS/params/RubyDebug.hh' not found, needed by target `build/ARM_FS/python/m5/internal/param_RubySystem_wrap.cc'. See /z/m5/regression/regress-2011-01-11-03:00:01 for details. ___ 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 -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: x86: Timing support for pagetable walker
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/396/ --- (Updated 2011-01-11 08:14:04.743657) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- x86: Timing support for pagetable walker Move page table walker state to its own object type, and make the walker instantiate state for each outstanding walk. By storing the states in a queue, the walker is able to handle multiple outstanding timing requests. Note that functional walks use separate state elements. Diffs (updated) - src/arch/x86/pagetable_walker.hh 9f9e10967912 src/arch/x86/pagetable_walker.cc 9f9e10967912 src/arch/x86/tlb.hh 9f9e10967912 src/arch/x86/tlb.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/396/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
I also received this error after I pulled in Nate's changeset. Removing the build directory fixed the problem for me. That rings a bell. I think it happened, but I'm not sure why that happened. I'll blow away the build directory on zizzer. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: mem: Added support for Null data packet
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/399/ --- (Updated 2011-01-11 09:27:55.596573) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- mem: Added support for Null data packet The packet now identifies whether static or dynamic data has been allocated and is used by Ruby to determine whehter to copy the data pointer into the ruby request. Ruby does not currently support array data. Diffs (updated) - src/mem/packet.hh 9f9e10967912 src/mem/ruby/system/DMASequencer.cc 9f9e10967912 src/mem/ruby/system/RubyPort.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/399/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Fixes MESI CMP directory protocol
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/#review721 --- After you delete the commented out lines, please check it in. I was leery of silently dropping those L1_PUTXes and I'm glad to see the L2 no longer does that. src/mem/protocol/MESI_CMP_directory-L2cache.sm http://reviews.m5sim.org/r/420/#comment988 Please delete these commented out lines - Brad On 2011-01-10 11:48:16, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/420/ --- (Updated 2011-01-10 11:48:16) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Ruby: Fixes MESI CMP directory protocol The current implementation of MESI CMP directory protocol is broken. This patch, from Arkaprava Basu, fixes the protocol. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm c06505ff551e src/mem/protocol/MESI_CMP_directory-L2cache.sm c06505ff551e Diff: http://reviews.m5sim.org/r/420/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Hi Nilay,
Sure, using a local variable to further reduce the calls to getCacheEntry is a
great idea. I think that is orthogonal to the suggestion I was making. I just
want the ability to directly set the cache_entry and tbe_entry variables in the
trigger function. That way the address, cache_entry, and tbe_entry variables
are dealt with consistently and it avoids adding the separate calls to
set_cache_entry() and set_tbe () in the inports.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Friday, January 07, 2011 11:40 AM
To: Beckmann, Brad
Cc: Default
Subject: RE: Review Request: Changing how CacheMemory interfaces with SLICC
Brad, my comments are inline.
On Fri, 7 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
Unfortunately I can't provide you an example of a protocol where
getCacheEntry behaves in a different manner, but they do exist. I
reviewed your most recent patch updates and I don't think what we're
asking for is much different than what you have on reviewboard right
now. Basically, all we need to do is add back in the capability for
the programmer to write their own getCacheEntry function in the .sm file.
I know that I initially asked you to automatically generate those
functions, and I still think that is useful for most protocols, but
Lisa made me realize that we need customized getCacheEntry functions as well.
Also we may want to change the name of generated getCacheEntry
function to getExclusiveCacheEntry so that one realizes the exclusive
assumption made by the function.
Other than that, the only other change I suggest is to allow the trigger
function to directly set the implicit cache_entry and tbe_entry
variables. Below is example of what I'm envisioning:
[Nilay] If we do things in this way, then any in_port, in which cache / tb
entries are accessed before the trigger function, would still make calls
to isCacheTagPresent().
Currently in MOESI_CMP_directory-L1cache.sm:
in_port(useTimerTable_in, Address, useTimerTable) {
if (useTimerTable_in.isReady()) {
set_cache_entry(getCacheEntry(useTimerTable.readyAddress()));
set_tbe(TBEs[useTimerTable.readyAddress()]);
trigger(Event:Use_Timeout, useTimerTable.readyAddress());
}
}
Replace that with the following:
in_port(useTimerTable_in, Address, useTimerTable) {
if (useTimerTable_in.isReady()) {
trigger(Event:Use_Timeout, useTimerTable.readyAddress(),
getExclusiveCacheEntry(useTimerTable.readyAddress()),
TBEs[useTimerTable.readyAddress()]);
}
}
[Nilay] Instead of passing cache and tb entries as arguments, we can
create local variables in the trigger function using the address argument.
Please let me know if you have any questions.
Thanks...you're almost done. :)
Brad
Thanks
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: m5: added work completed monitoring support
I'd advise against putting the comments in two places since they probably wouldn't stay in sync/up to date. You could refer from one comment to the other, though, and have it in two places through indirection. Gabe On 01/10/11 16:45, Ali Saidi wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/418/ On January 9th, 2011, 6:39 p.m., *Ali Saidi* wrote: src/sim/pseudo_inst.cc http://reviews.m5sim.org/r/418/diff/1/?file=9397#file9397line329 (Diff revision 1) debugbreak(ThreadContext *tc) 329 void There needs to be a good comment about why you would use this here and the wiki page needs to be updated On January 10th, 2011, 11:48 a.m., *Brad Beckmann* wrote: I'm confused. These work completed functions are following the same convention as other pseudo instructions that involve the thread context. Both sets of functions do most of their logic in pseudo_inst. Why should the guts of the work functions be moved to system? Or are you suggesting a different change? On January 10th, 2011, 3:50 p.m., *Ali Saidi* wrote: I'm not suggesting that they're moved to system. I'm just saying that they need a good comment that describes their purpose and use. On January 10th, 2011, 4:28 p.m., *Brad Beckmann* wrote: I added a few more comments, but I'm not sure if it is what you are looking for. It seems a little overkill to put more any comments into pseudo_inst.cc, since no other functions in this file are commented at all. I do agree that we need to document on the wiki about how to use these annotations. I think we should include that in our planned overhaul of the wiki, since I don't see a good place to put it right now. Please let me know if you have a good suggestion. Thanks. Looks good to me. I realize that there aren't any other instructions in there that are documented, but I think that is an oversight. After digging through src/base it became clear to me that we write code knowing exactly what it does and what it should be used for and then forget about it. I think the comments you created would actually be better as doxygen comments in system.hh for incWorkItemsBegin() incWorkItemsEnd() and markWorkItem(). Both places might be good. Thanks again. - Ali On January 10th, 2011, 4:21 p.m., Brad Beckmann wrote: Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. By Brad Beckmann. /Updated 2011-01-10 16:21:58/ Description m5: added work completed monitoring support Diffs * configs/common/FSConfig.py (9f9e10967912) * configs/common/Options.py (9f9e10967912) * configs/example/fs.py (9f9e10967912) * configs/example/ruby_fs.py (9f9e10967912) * src/arch/x86/isa/decoder/two_byte_opcodes.isa (9f9e10967912) * src/cpu/base.hh (9f9e10967912) * src/cpu/base.cc (9f9e10967912) * src/sim/SConscript (9f9e10967912) * src/sim/System.py (9f9e10967912) * src/sim/pseudo_inst.hh (9f9e10967912) * src/sim/pseudo_inst.cc (9f9e10967912) * src/sim/system.hh (9f9e10967912) * src/sim/system.cc (9f9e10967912) * util/m5/m5op_x86.S (9f9e10967912) * util/m5/m5ops.h (9f9e10967912) View Diff http://reviews.m5sim.org/r/418/diff/ ___ 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: mem: Added support for Null data packet
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/399/#review722 --- Ship it! - Steve On 2011-01-11 09:27:55, Brad Beckmann wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/399/ --- (Updated 2011-01-11 09:27:55) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- mem: Added support for Null data packet The packet now identifies whether static or dynamic data has been allocated and is used by Ruby to determine whehter to copy the data pointer into the ruby request. Ruby does not currently support array data. Diffs - src/mem/packet.hh 9f9e10967912 src/mem/ruby/system/DMASequencer.cc 9f9e10967912 src/mem/ruby/system/RubyPort.cc 9f9e10967912 Diff: http://reviews.m5sim.org/r/399/diff Testing --- Thanks, Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
On Tue, 11 Jan 2011, Beckmann, Brad wrote: Hi Nilay, Sure, using a local variable to further reduce the calls to getCacheEntry is a great idea. I think that is orthogonal to the suggestion I was making. I just want the ability to directly set the cache_entry and tbe_entry variables in the trigger function. That way the address, cache_entry, and tbe_entry variables are dealt with consistently and it avoids adding the separate calls to set_cache_entry() and set_tbe () in the inports. Firstly, we have to set cache and transaction buffer entry variables whenever we do allocation or deallocation of entries. This means these calls cannot be completely avoided. Secondly, while processing events from the mandatory queue (as it is called in the current implementations), if these variables are not set, we will have to revert to the earlier approach. This would double the number of times cache entry lookups are performed as the trigger function will perform the lookup again. This would also mean that both the approaches for looking up cache entry in the cache will have to exist simultaneously. Another concern is in implementation of getCacheEntry(). If this function has to return a pointer to a cache entry, we would have to provide support for local variables which internally SLICC would assume to be pointer variables. In my opinion, we should maintain one method for looking up cache entries. My own experience informs me that it is not difficult to incorporate calls to set/unset_cache_entry () in already existing protocol implementations. For implementing new protocols, I think the greater obstacle will be in implementing the protocol correctly and not in using entry variables correctly. If we document this change lucidly, there is no reason to believe a SLICC programmer will be exceptionally pushed because of this change. Assuming that this change does introduce some complexity in progamming with SLICC, does that complexity out weigh the performance improvements? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Sure, using a local variable to further reduce the calls to getCacheEntry is a great idea. I think that is orthogonal to the suggestion I was making. I just want the ability to directly set the cache_entry and tbe_entry variables in the trigger function. That way the address, cache_entry, and tbe_entry variables are dealt with consistently and it avoids adding the separate calls to set_cache_entry() and set_tbe () in the inports. Firstly, we have to set cache and transaction buffer entry variables whenever we do allocation or deallocation of entries. This means these calls cannot be completely avoided. Secondly, while processing events from the mandatory queue (as it is called in the current implementations), if these variables are not set, we will have to revert to the earlier approach. This would double the number of times cache entry lookups are performed as the trigger function will perform the lookup again. This would also mean that both the approaches for looking up cache entry in the cache will have to exist simultaneously. Absolutely, we still need the ability to allocate or deallocate entries within actions. I'm not advocating to completely eliminate the set/unset cache and tbe entry functions. I just want to avoid including those calls in the inports. I'm confused why the mandatory queue is different than other queues. They all trigger events in the same way. Maybe I should point out that I'm assuming that getCacheEntry can return a NULL pointer and thus that can be passed into the trigger call when no cache or tbe entry exists. Another concern is in implementation of getCacheEntry(). If this function has to return a pointer to a cache entry, we would have to provide support for local variables which internally SLICC would assume to be pointer variables. Within SLICC understanding that certain variables are actually pointers is a little bit of a nuisance, but there already exists examples where we make that distinction. For instance, look at the if para.pointer conditionals in StateMachine.py. We just have to treat cache and tbe entries in the same fashion. In my opinion, we should maintain one method for looking up cache entries. My own experience informs me that it is not difficult to incorporate calls to set/unset_cache_entry () in already existing protocol implementations. For implementing new protocols, I think the greater obstacle will be in implementing the protocol correctly and not in using entry variables correctly. If we document this change lucidly, there is no reason to believe a SLICC programmer will be exceptionally pushed because of this change. Assuming that this change does introduce some complexity in progamming with SLICC, does that complexity out weigh the performance improvements? My position is we can leverage SLICC as an intermediate language and achieve the performance benefits of your change without significantly impacting the programmability. I agree that we need the set/unset_cache_entry calls in the allocate and deallocate actions. I see no problem with that. I just want to treat these new implicit cache and tbe entry variables like the existing implicit variable address. Therefore I want to pass them into the trigger operation like the address variable. I also want just one method for looking up cache entries. I believe the only difference is that I would like to set the cache and tbe entries in the trigger function, as well as allowing them to be set in the actions. I hope that clarifies at least what I'm envisioning. I appreciate your feedback on this and I want to reiterate that I think your change is really close to being done. If you still feel like I'm missing something, I would be happy to chat with you over-the-phone. Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Brad, my comments are inline.
On Tue, 11 Jan 2011, Beckmann, Brad wrote:
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the trigger function. That way
the address, cache_entry, and tbe_entry variables are dealt with
consistently and it avoids adding the separate calls to
set_cache_entry() and set_tbe () in the inports.
Firstly, we have to set cache and transaction buffer entry variables whenever
we do allocation or deallocation of entries. This means these calls cannot be
completely avoided. Secondly, while processing events from the mandatory
queue (as it is called in the current implementations), if these variables are
not set, we will have to revert to the earlier approach. This would double the
number of times cache entry lookups are performed as the trigger function
will perform the lookup again. This would also mean that both the
approaches for looking up cache entry in the cache will have to exist
simultaneously.
Absolutely, we still need the ability to allocate or deallocate entries
within actions. I'm not advocating to completely eliminate the
set/unset cache and tbe entry functions. I just want to avoid including
those calls in the inports. I'm confused why the mandatory queue is
different than other queues. They all trigger events in the same way.
if (L1IcacheMemory.isTagPresent(in_msg.LineAddress)) {
// The tag matches for the L1, so the L1 asks the L2 for it.
trigger(mandatory_request_type_to_event(in_msg.Type), in_msg.LineAddress);
}
Brad, mandatory queue is just an example where an inport may perform tag
lookup before cache and transaction buffer entries has been set. Above is
an excerpt from the file MOESI_CMP_directory-L1cache.sm. Before the
trigger() is called, isTagPresent() is called. This means tag look up is
being performed before cache or transaction buffer entries have been set.
Suppose the tag was present in L1Icache, then in the trigger() call, we
will again perform lookup.
Similarly, there is an inport in the Hammer's protocol implementation
where getCacheEntry() is called before a call to trigger(). Now, why
should we use getCacheEntry() in the inport and cache entry in the action?
In MESI_CMP_directory, getState() is called from an inport. This means we
cannot have an implementation of getState() that makes use of cache entry
variable since it would not have been set. Now, different implementations
for setState() and getState() simply does not make sense to me, so in my
opinion setState() will also not use cache entry. These two function (I
just went through the profile output for MOESI hammer), account for about
half of the calls to isTagPresent(), the function that we are trying to
get rid of.
Maybe I should point out that I'm assuming that getCacheEntry can return
a NULL pointer and thus that can be passed into the trigger call when no
cache or tbe entry exists.
You are correct that getCacheEntry() would have to return a NULL, another
thing which I believe we earlier preferred avoiding. As an aside, we
cannot use the keyword NULL since it is already in use. So, we will have
to rename NULL as some thing else.
On second thought, I think it may not be necessary for getCacheEntry() to
use the keyword.
Another concern is in implementation of getCacheEntry(). If this function has
to return a pointer to a cache entry, we would have to provide support for
local variables which internally SLICC would assume to be pointer variables.
Within SLICC understanding that certain variables are actually pointers
is a little bit of a nuisance, but there already exists examples where
we make that distinction. For instance, look at the if para.pointer
conditionals in StateMachine.py. We just have to treat cache and tbe
entries in the same fashion.
I know it is possible to declare pointers in SLICC, CacheMemory being the
foremost example. But we only allow declaration of pointers. We tacitly
assume that when ever they will be used, they will only be used after
being dereferenced. Now, in case of getCacheEntry(), I do not see this
happening. Below is the current implementation of getCacheEntry() from
MOESI_CMP_directory-L1cache.sm.
Entry getCacheEntry(Address addr), return_by_ref=yes {
if (L1DcacheMemory.isTagPresent(addr)) {
return static_cast(Entry, L1DcacheMemory[addr]);
} else {
return static_cast(Entry, L1IcacheMemory[addr]);
}
}
I would probably convert it to some thing like this.
AbstractCacheEntry getCacheEntry(Address addr) {
AbstractCacheEntry * cache_entry = L1DcacheMemory.lookup(addr);
if(is_valid(cache_entry)) return cache_entry;
return L1IcacheMemory.lookup(addr);
}
Now, if we assume that cache_entry will always be used in its dereferenced
form, then we will face problem in returning cache
Re: [m5-dev] changeset in m5: Mem: Finish half-baked support for mmaping file...
I just had this break a few checkpoints myself - and it's not a big deal
really because it's easily fixup-able...but I wonder whether you really want
to serialize the size of the physmem - let's say you run a checkpointing run
with physmem N gigs and then you restore with physmem M gigs...I don't see
why the size of the physmem needs to be serialized or unserialized at all
and overwrite the simulation-configured size. Is there a compelling reason
to do so?
Lisa
On Thu, Dec 9, 2010 at 8:51 PM, Beckmann, Brad brad.beckm...@amd.comwrote:
Hi Ali,
This is changset 7730 which also breaks all previous checkpoints because it
requires phsymem to serialize and unserialize the variable _size.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Ali Saidi
Sent: Monday, November 08, 2010 11:59 AM
To: m5-dev@m5sim.org
Subject: [m5-dev] changeset in m5: Mem: Finish half-baked support for
mmaping file...
changeset 982b4c6c1470 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=982b4c6c1470
description:
Mem: Finish half-baked support for mmaping file in physmem.
Physmem has a parameter to be able to mem map a file, however
it isn't actually used. This changeset utilizes the parameter
so a file can be mmapped.
diffstat:
configs/common/FSConfig.py | 8 ++-
src/mem/physical.cc| 48 +++--
src/mem/physical.hh| 8 +++---
3 files changed, 44 insertions(+), 20 deletions(-)
diffs (176 lines):
diff -r d3c006ecccd3 -r 982b4c6c1470 configs/common/FSConfig.py
--- a/configs/common/FSConfig.py Mon Nov 08 13:58:24 2010 -0600
+++ b/configs/common/FSConfig.py Mon Nov 08 13:58:24 2010 -0600
@@ -200,9 +200,12 @@
self.membus.badaddr_responder.warn_access = warn
self.bridge = Bridge(delay='50ns', nack_delay='4ns')
self.physmem = PhysicalMemory(range = AddrRange(mdesc.mem()), zero
= True)
+self.diskmem = PhysicalMemory(range = AddrRange(Addr('128MB'),
size = '128MB'),
+ file = disk('ael-arm.ext2'))
self.bridge.side_a = self.iobus.port
self.bridge.side_b = self.membus.port
self.physmem.port = self.membus.port
+self.diskmem.port = self.membus.port
self.mem_mode = mem_mode
@@ -224,7 +227,10 @@
self.intrctrl = IntrControl()
self.terminal = Terminal()
-self.boot_osflags = 'earlyprintk mem=128MB console=ttyAMA0
lpj=19988480 norandmaps'
+self.kernel = binary('vmlinux.arm')
+self.boot_osflags = 'earlyprintk mem=128MB console=ttyAMA0
lpj=19988480' + \
+' norandmaps
slram=slram0,0x800,+0x800' + \
+' mtdparts=slram0:- rw loglevel=8
root=/dev/mtdblock0'
return self
diff -r d3c006ecccd3 -r 982b4c6c1470 src/mem/physical.cc
--- a/src/mem/physical.cc Mon Nov 08 13:58:24 2010 -0600
+++ b/src/mem/physical.cc Mon Nov 08 13:58:24 2010 -0600
@@ -31,6 +31,7 @@
#include sys/types.h
#include sys/mman.h
+#include sys/user.h
#include errno.h
#include fcntl.h
#include unistd.h
@@ -41,6 +42,7 @@
#include string
#include arch/registers.hh
+#include base/intmath.hh
#include base/misc.hh
#include base/random.hh
#include base/types.hh
@@ -56,26 +58,39 @@
PhysicalMemory::PhysicalMemory(const Params *p)
: MemObject(p), pmemAddr(NULL), pagePtr(0),
lat(p-latency), lat_var(p-latency_var),
- cachedSize(params()-range.size()), cachedStart(params()-
range.start)
+ _size(params()-range.size()), _start(params()-range.start)
{
-if (params()-range.size() % TheISA::PageBytes != 0)
+if (size() % TheISA::PageBytes != 0)
panic(Memory Size not divisible by page size\n);
if (params()-null)
return;
-int map_flags = MAP_ANON | MAP_PRIVATE;
-pmemAddr = (uint8_t *)mmap(NULL, params()-range.size(),
- PROT_READ | PROT_WRITE, map_flags, -1,
0);
+
+if (params()-file == ) {
+int map_flags = MAP_ANON | MAP_PRIVATE;
+pmemAddr = (uint8_t *)mmap(NULL, size(),
+ PROT_READ | PROT_WRITE, map_flags,
-1, 0);
+} else {
+int map_flags = MAP_PRIVATE;
+int fd = open(params()-file.c_str(), O_RDONLY);
+_size = lseek(fd, 0, SEEK_END);
+lseek(fd, 0, SEEK_SET);
+pmemAddr = (uint8_t *)mmap(NULL, roundUp(size(), PAGE_SIZE),
+ PROT_READ | PROT_WRITE, map_flags,
fd, 0);
+}
if (pmemAddr == (void *)MAP_FAILED) {
perror(mmap);
-fatal(Could not mmap!\n);
+if (params()-file == )
+fatal(Could not mmap!\n);
+else
+fatal(Could not find file: %s\n,
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Hi Nilay,
Overall, I believe we are in more agreement with each other than maybe you
think. I'm glad you included pseudo code in your latest email. That is a
great idea. I think part of our problem is we are comprehending our textual
descriptions in different ways.
Below are my responses:
Absolutely, we still need the ability to allocate or deallocate
entries within actions. I'm not advocating to completely eliminate
the set/unset cache and tbe entry functions. I just want to avoid
including those calls in the inports. I'm confused why the mandatory
queue is different than other queues. They all trigger events in the same
way.
if (L1IcacheMemory.isTagPresent(in_msg.LineAddress)) {
// The tag matches for the L1, so the L1 asks the L2 for it.
trigger(mandatory_request_type_to_event(in_msg.Type),
in_msg.LineAddress); }
Brad, mandatory queue is just an example where an inport may perform tag
lookup before cache and transaction buffer entries has been set. Above is an
excerpt from the file MOESI_CMP_directory-L1cache.sm. Before the
trigger() is called, isTagPresent() is called. This means tag look up is being
performed before cache or transaction buffer entries have been set.
Suppose the tag was present in L1Icache, then in the trigger() call, we will
again perform lookup.
Similarly, there is an inport in the Hammer's protocol implementation where
getCacheEntry() is called before a call to trigger(). Now, why should we use
getCacheEntry() in the inport and cache entry in the action?
The reason is, as you pointed out, we ideally want to call getCacheEntry once.
I believe your suggestion to use local variables in the input ports gets us
there. Below is what I'm envisioning for the MOESI_hammer mandatory queue
in_port logic (at least the IFETCH half of the logic):
ENTRY getL1ICacheEntry(Address addr) {
assert(is_valid(L1DcacheMemory.lookup(addr) == FALSE);
assert(is_valid(L2cacheMemory.lookup(addr) == FALSE);
return L1IcacheMemory.lookup(addr);
}
ENTRY getL1DCacheEntry(Address addr) {
assert(is_valid(L1IcacheMemory.lookup(addr) == FALSE);
assert(is_valid(L2cacheMemory.lookup(addr) == FALSE);
return L1DcacheMemory.lookup(addr);
}
ENTRY getL2CacheEntry(Address addr) {
assert(is_valid(L1IcacheMemory.lookup(addr) == FALSE);
assert(is_valid(L1DcacheMemory.lookup(addr) == FALSE);
return L2cacheMemory.lookup(addr);
}
in_port(mandatoryQueue_in, CacheMsg, mandatoryQueue, desc=..., rank=0) {
if (mandatoryQueue_in.isReady()) {
peek(mandatoryQueue_in, CacheMsg, block_on=LineAddress) {
// Set the local entry variables
ENTRY L1I_cache_entry = getL1ICacheEntry(in_msg.LineAddress);
ENTRY L1D_cache_entry = getL1DCacheEntry(in_msg.LineAddress);
TBE_Entry tbe_entry = getTBE(in_msg.LineAddress);
// Check for data access to blocks in I-cache and ifetchs to blocks in
D-cache
if (in_msg.Type == CacheRequestType:IFETCH) {
// ** INSTRUCTION ACCESS ***
// Check to see if it is in the OTHER L1
if (is_valid(L1D_cache_entry)) {
// The block is in the wrong L1, try to write it to the L2
if (L2cacheMemory.cacheAvail(in_msg.LineAddress)) {
trigger(Event:L1_to_L2, in_msg.LineAddress, L1D_cache_entry,
tbe_entry);
} else {
replace_addr = L2cacheMemory.cacheProbe(in_msg.LineAddress);
replace_cache_entry = getL2CacheEntry(replace_addr);
replace_tbe_entry = getTBE(replace_addr);
trigger(Event:L2_Replacement, replace_addr, replace_cache_entry,
replace_tbe_entry);
}
}
if (is_valid(L1I_cache_entry)) {
// The tag matches for the L1, so the L1 fetches the line. We know
it can't be in the L2 due to exclusion
trigger(mandatory_request_type_to_event(in_msg.Type),
in_msg.LineAddress, L1I_cache_entry, tbe_entry);
} else {
if (L1IcacheMemory.cacheAvail(in_msg.LineAddress)) {
// L1 does't have the line, but we have space for it in the L1
ENTRY L2_cache_entry = getL2CacheEntry(in_msg.LineAddress);
if (is_valid(L2_cache_entry)) {
// L2 has it (maybe not with the right permissions)
trigger(Event:Trigger_L2_to_L1I, in_msg.LineAddress,
L2_cache_entry, tbe_entry);
} else {
// We have room, the L2 doesn't have it, so the L1 fetches the
line
trigger(mandatory_request_type_to_event(in_msg.Type),
in_msg.LineAddress, L1Icache_entry, tbe_entry);
// you could also say here:
trigger(mandatory_request_type_to_event(in_msg.Type), in_msg.LineAddress, ODD,
ODD);
}
} else {
// No room in the L1, so we need to make room
if
(L2cacheMemory.cacheAvail(L1IcacheMemory.cacheProbe(in_msg.LineAddress))) {
Re: [m5-dev] Review Request: Changing how CacheMemory interfaces with SLICC
Hi Nilay,
I've been talking with Brad here at work about some of these things so I
will finally jump into the conversation via email. First, great job on this
- this has clearly been a substantial amount of work. I'm impressed.
I've got some comments below.
On Tue, Jan 11, 2011 at 3:46 PM, Nilay Vaish ni...@cs.wisc.edu wrote:
Brad, my comments are inline.
On Tue, 11 Jan 2011, Beckmann, Brad wrote:
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the trigger function. That way
the address, cache_entry, and tbe_entry variables are dealt with
consistently and it avoids adding the separate calls to
set_cache_entry() and set_tbe () in the inports.
Firstly, we have to set cache and transaction buffer entry variables
whenever
we do allocation or deallocation of entries. This means these calls
cannot be
completely avoided. Secondly, while processing events from the mandatory
queue (as it is called in the current implementations), if these
variables are
not set, we will have to revert to the earlier approach. This would
double the
number of times cache entry lookups are performed as the trigger function
will perform the lookup again. This would also mean that both the
approaches for looking up cache entry in the cache will have to exist
simultaneously.
Absolutely, we still need the ability to allocate or deallocate entries
within actions. I'm not advocating to completely eliminate the set/unset
cache and tbe entry functions. I just want to avoid including those calls
in the inports. I'm confused why the mandatory queue is different than
other queues. They all trigger events in the same way.
if (L1IcacheMemory.isTagPresent(in_msg.LineAddress)) {
// The tag matches for the L1, so the L1 asks the L2 for it.
trigger(mandatory_request_type_to_event(in_msg.Type), in_msg.LineAddress);
}
Brad, mandatory queue is just an example where an inport may perform tag
lookup before cache and transaction buffer entries has been set. Above is an
excerpt from the file MOESI_CMP_directory-L1cache.sm. Before the trigger()
is called, isTagPresent() is called. This means tag look up is being
performed before cache or transaction buffer entries have been set. Suppose
the tag was present in L1Icache, then in the trigger() call, we will again
perform lookup.
Similarly, there is an inport in the Hammer's protocol implementation where
getCacheEntry() is called before a call to trigger(). Now, why should we use
getCacheEntry() in the inport and cache entry in the action?
I'm not sure why having the trigger function implicitly set the cache
entries and tbe entries would require two calls to isTagPresent() if local
variables are involved. Is there some reason why something like the code
below would not be possible?
local_var := getL1ICacheEntry(in_msg.LineAddress)
if (is_valid(local_var))
trigger(Event, in_msg.LineAddress, local_var);
I don't see how having the entries being passed to the trigger function is
functionally different than having to explicitly set things using two
function calls is different - as long as there is a local variable involved
to carry the value across some in_port logic it seems much cleaner and more
consistent to eliminate the need to explicitly call two functions for every
in_port.
I just saw Brad's latest email go by with pseudocode and I think that is
both clean and flexible/functional - in certain cases you can explicitly
make the getCacheEntry call you want, depending on your protocol, in the
call to the trigger function, and in others you can set entries beforehand
into local variables and do arbitrary logic, then pass whatever entry you
want to the trigger function.
Lisa
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: Mem: Finish half-baked support for mmaping file...
I haven't followed this thread closely, but I don't understand this response.
Nate
Yes, because if you're mmapping a file, it's likely that the file is
slightly smaller than the size of memory allocated.
Ali
On Jan 11, 2011, at 5:50 PM, Lisa Hsu wrote:
I just had this break a few checkpoints myself - and it's not a big deal
really because it's easily fixup-able...but I wonder whether you really want
to serialize the size of the physmem - let's say you run a checkpointing run
with physmem N gigs and then you restore with physmem M gigs...I don't see
why the size of the physmem needs to be serialized or unserialized at all
and overwrite the simulation-configured size. Is there a compelling reason
to do so?
Lisa
On Thu, Dec 9, 2010 at 8:51 PM, Beckmann, Brad brad.beckm...@amd.com
wrote:
Hi Ali,
This is changset 7730 which also breaks all previous checkpoints because
it requires phsymem to serialize and unserialize the variable _size.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Ali Saidi
Sent: Monday, November 08, 2010 11:59 AM
To: m5-dev@m5sim.org
Subject: [m5-dev] changeset in m5: Mem: Finish half-baked support for
mmaping file...
changeset 982b4c6c1470 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=982b4c6c1470
description:
Mem: Finish half-baked support for mmaping file in physmem.
Physmem has a parameter to be able to mem map a file, however
it isn't actually used. This changeset utilizes the parameter
so a file can be mmapped.
diffstat:
configs/common/FSConfig.py | 8 ++-
src/mem/physical.cc | 48 +++--
src/mem/physical.hh | 8 +++---
3 files changed, 44 insertions(+), 20 deletions(-)
diffs (176 lines):
diff -r d3c006ecccd3 -r 982b4c6c1470 configs/common/FSConfig.py
--- a/configs/common/FSConfig.py Mon Nov 08 13:58:24 2010 -0600
+++ b/configs/common/FSConfig.py Mon Nov 08 13:58:24 2010 -0600
@@ -200,9 +200,12 @@
self.membus.badaddr_responder.warn_access = warn
self.bridge = Bridge(delay='50ns', nack_delay='4ns')
self.physmem = PhysicalMemory(range = AddrRange(mdesc.mem()), zero
= True)
+ self.diskmem = PhysicalMemory(range = AddrRange(Addr('128MB'),
size = '128MB'),
+ file = disk('ael-arm.ext2'))
self.bridge.side_a = self.iobus.port
self.bridge.side_b = self.membus.port
self.physmem.port = self.membus.port
+ self.diskmem.port = self.membus.port
self.mem_mode = mem_mode
@@ -224,7 +227,10 @@
self.intrctrl = IntrControl()
self.terminal = Terminal()
- self.boot_osflags = 'earlyprintk mem=128MB console=ttyAMA0
lpj=19988480 norandmaps'
+ self.kernel = binary('vmlinux.arm')
+ self.boot_osflags = 'earlyprintk mem=128MB console=ttyAMA0
lpj=19988480' + \
+ ' norandmaps
slram=slram0,0x800,+0x800' + \
+ ' mtdparts=slram0:- rw loglevel=8
root=/dev/mtdblock0'
return self
diff -r d3c006ecccd3 -r 982b4c6c1470 src/mem/physical.cc
--- a/src/mem/physical.cc Mon Nov 08 13:58:24 2010 -0600
+++ b/src/mem/physical.cc Mon Nov 08 13:58:24 2010 -0600
@@ -31,6 +31,7 @@
#include sys/types.h
#include sys/mman.h
+#include sys/user.h
#include errno.h
#include fcntl.h
#include unistd.h
@@ -41,6 +42,7 @@
#include string
#include arch/registers.hh
+#include base/intmath.hh
#include base/misc.hh
#include base/random.hh
#include base/types.hh
@@ -56,26 +58,39 @@
PhysicalMemory::PhysicalMemory(const Params *p)
: MemObject(p), pmemAddr(NULL), pagePtr(0),
lat(p-latency), lat_var(p-latency_var),
- cachedSize(params()-range.size()), cachedStart(params()-
range.start)
+ _size(params()-range.size()), _start(params()-range.start)
{
- if (params()-range.size() % TheISA::PageBytes != 0)
+ if (size() % TheISA::PageBytes != 0)
panic(Memory Size not divisible by page size\n);
if (params()-null)
return;
- int map_flags = MAP_ANON | MAP_PRIVATE;
- pmemAddr = (uint8_t *)mmap(NULL, params()-range.size(),
- PROT_READ | PROT_WRITE, map_flags, -1,
0);
+
+ if (params()-file == ) {
+ int map_flags = MAP_ANON | MAP_PRIVATE;
+ pmemAddr = (uint8_t *)mmap(NULL, size(),
+ PROT_READ | PROT_WRITE, map_flags,
-1, 0);
+ } else {
+ int map_flags = MAP_PRIVATE;
+ int fd = open(params()-file.c_str(), O_RDONLY);
+ _size = lseek(fd, 0, SEEK_END);
+ lseek(fd, 0, SEEK_SET);
+ pmemAddr = (uint8_t *)mmap(NULL, roundUp(size(), PAGE_SIZE),
+ PROT_READ | PROT_WRITE,
[m5-dev] Potential bugs when generating ALPHA_FS with ruby
Hello, everyone, In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory by just changing the ALPHA_SE_MOESI_CMP_directory to the following script. FULL_SYSTEM = 1 SS_COMPATIBLE_FP = 1 CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU' PROTOCOL = 'MOESI_CMP_directory' RUBY = True But I got the errors as follows when building it, which I believe indicates certain bugs. build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc: In member function 'void InOrderCPU::processInterrupts(Fault)': build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected type-specifier before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: conversion from 'int*' to non-scalar type 'ThePipeline::DynInstPtr' requested build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected ',' or ';' before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:634: error: no matching function for call to 'InOrderCPU::trap(Fault, ThePipeline::DynInstPtr)' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.hh:344: note: candidates are: void InOrderCPU::trap(Fault, ThreadID, ThePipeline::DynInstPtr, int) In line 633 of src/cpu/inorder/cpu.cc, it complains that Impl::DynInst is not a correct class name. The problem couldn't be worked around by removing Impl::. In line 634 of the same file, only two variables are passed to the trap function but apparently it needs another ThreadID type variable. Since I am not quite familiar with the source code in the cpu folder, I just raise my questions on the errors and hope someone can fix it. Thanks, Leonard -- Give our ability to our work, but our genius to our life! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Potential bugs when generating ALPHA_FS with ruby
I'll check those errors out for you, but InOrder doesnt currently work in FS mode, so you would be OK to remove that from your build options if you so chose. On Tue, Jan 11, 2011 at 11:14 PM, Sage leonard...@gmail.com wrote: Hello, everyone, In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory by just changing the ALPHA_SE_MOESI_CMP_directory to the following script. FULL_SYSTEM = 1 SS_COMPATIBLE_FP = 1 CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU' PROTOCOL = 'MOESI_CMP_directory' RUBY = True But I got the errors as follows when building it, which I believe indicates certain bugs. build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc: In member function 'void InOrderCPU::processInterrupts(Fault)': build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected type-specifier before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: conversion from 'int*' to non-scalar type 'ThePipeline::DynInstPtr' requested build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected ',' or ';' before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:634: error: no matching function for call to 'InOrderCPU::trap(Fault, ThePipeline::DynInstPtr)' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.hh:344: note: candidates are: void InOrderCPU::trap(Fault, ThreadID, ThePipeline::DynInstPtr, int) In line 633 of src/cpu/inorder/cpu.cc, it complains that Impl::DynInst is not a correct class name. The problem couldn't be worked around by removing Impl::. In line 634 of the same file, only two variables are passed to the trap function but apparently it needs another ThreadID type variable. Since I am not quite familiar with the source code in the cpu folder, I just raise my questions on the errors and hope someone can fix it. Thanks, Leonard -- Give our ability to our work, but our genius to our life! ___ 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] Data type of Stats::Counter
I don't know the range of numbers that we deal with, but floating numbers may not exactly represent integers. It is possible to construct integers 2^53 which are not exactly representable, I think (2^53)+1 cannot be represented exactly. In fact, in such a case, 'a++' might end up equal to 'a' itself. Now such huge numbers can be reached if the simulation were to run for months (assuming only increments by one are made). Therefore it might not be a problem. But floating point addition is costly compared to integer addition, then why go for floating point? On Mon, January 10, 2011 4:00 pm, nathan binkert wrote: /** All counters are of 64-bit values. */ typedef double Counter; This line is from src/base/stats/types.hh. It seems intentional. But this will not work correctly for all arithmetic operations on variables of type Counter. Can't we use int64_t instead? What exactly won't work? At one point (way long ago), I think counters were int64_t, but the change could have unforeseen effects. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Data type of Stats::Counter
I don't know the range of numbers that we deal with, but floating numbers may not exactly represent integers. It is possible to construct integers 2^53 which are not exactly representable, I think (2^53)+1 cannot be represented exactly. In fact, in such a case, 'a++' might end up equal to 'a' itself. I'm pretty sure that we won't run into this. There are 31.5 Million seconds/year. Or 31.5e15 nanoseconds per year. 2^53 is 9.0e15. That means that you'd have to increment that counter every nanosecond to hit the problem in four months. Now in theory, if you were to increment by 1000 once per nanosecond for 3 hours and then you tried to increment by one, the 1 would be lost. The question then becomes, would that just be noise? (I'd think so). Now such huge numbers can be reached if the simulation were to run for months (assuming only increments by one are made). Therefore it might not be a problem. But floating point addition is costly compared to integer addition, then why go for floating point? Is it really true that floating point adds are much more expensive than integer ones these days? Anyway, I'm quite happy for you to try changing it to an int64_t and thoroughly test the results. I think that Counter was once indeed int64_t. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Potential bugs when generating ALPHA_FS with ruby
Hi, Korey, Thanks for your reply. But even after I removed “InOrderCPU” from the CPU_MODELS list and cleaned up the build folder, source files related to the inorder model would still be compiled and the same errors would show up again. Thanks, Leonard On Tue, Jan 11, 2011 at 10:36 PM, Korey Sewell ksew...@umich.edu wrote: I'll check those errors out for you, but InOrder doesnt currently work in FS mode, so you would be OK to remove that from your build options if you so chose. On Tue, Jan 11, 2011 at 11:14 PM, Sage leonard...@gmail.com wrote: Hello, everyone, In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory by just changing the ALPHA_SE_MOESI_CMP_directory to the following script. FULL_SYSTEM = 1 SS_COMPATIBLE_FP = 1 CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU' PROTOCOL = 'MOESI_CMP_directory' RUBY = True But I got the errors as follows when building it, which I believe indicates certain bugs. build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc: In member function 'void InOrderCPU::processInterrupts(Fault)': build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected type-specifier before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: conversion from 'int*' to non-scalar type 'ThePipeline::DynInstPtr' requested build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected ',' or ';' before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:634: error: no matching function for call to 'InOrderCPU::trap(Fault, ThePipeline::DynInstPtr)' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.hh:344: note: candidates are: void InOrderCPU::trap(Fault, ThreadID, ThePipeline::DynInstPtr, int) In line 633 of src/cpu/inorder/cpu.cc, it complains that Impl::DynInst is not a correct class name. The problem couldn't be worked around by removing Impl::. In line 634 of the same file, only two variables are passed to the trap function but apparently it needs another ThreadID type variable. Since I am not quite familiar with the source code in the cpu folder, I just raise my questions on the errors and hope someone can fix it. Thanks, Leonard -- Give our ability to our work, but our genius to our life! ___ 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 -- Give our ability to our work, but our genius to our life! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Potential bugs when generating ALPHA_FS with ruby
We should be discussing this on m5-users, and it's probably better to set those parameters on the scons command line than in the file with the default settings. If you run scons --help, or scons --help build/ALPHA_SE_MOESI_CMP_directory/m5.opt in this case, it will print out what setting it's using for those variables. The file you're modifying is for the default values, and once those are in use I don't know exactly what you need to do to get them to be read in again. Gabe On 01/11/11 21:02, Sage wrote: Hi, Korey, Thanks for your reply. But even after I removed “InOrderCPU” from the CPU_MODELS list and cleaned up the build folder, source files related to the inorder model would still be compiled and the same errors would show up again. Thanks, Leonard On Tue, Jan 11, 2011 at 10:36 PM, Korey Sewell ksew...@umich.edu mailto:ksew...@umich.edu wrote: I'll check those errors out for you, but InOrder doesnt currently work in FS mode, so you would be OK to remove that from your build options if you so chose. On Tue, Jan 11, 2011 at 11:14 PM, Sage leonard...@gmail.com mailto:leonard...@gmail.com wrote: Hello, everyone, In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory by just changing the ALPHA_SE_MOESI_CMP_directory to the following script. FULL_SYSTEM = 1 SS_COMPATIBLE_FP = 1 CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU' PROTOCOL = 'MOESI_CMP_directory' RUBY = True But I got the errors as follows when building it, which I believe indicates certain bugs. build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc: In member function 'void InOrderCPU::processInterrupts(Fault)': build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected type-specifier before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: conversion from 'int*' to non-scalar type 'ThePipeline::DynInstPtr' requested build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected ',' or ';' before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:634: error: no matching function for call to 'InOrderCPU::trap(Fault, ThePipeline::DynInstPtr)' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.hh:344: note: candidates are: void InOrderCPU::trap(Fault, ThreadID, ThePipeline::DynInstPtr, int) In line 633 of src/cpu/inorder/cpu.cc, it complains that Impl::DynInst is not a correct class name. The problem couldn't be worked around by removing Impl::. In line 634 of the same file, only two variables are passed to the trap function but apparently it needs another ThreadID type variable. Since I am not quite familiar with the source code in the cpu folder, I just raise my questions on the errors and hope someone can fix it. Thanks, Leonard -- Give our ability to our work, but our genius to our life! ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org mailto:m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- Give our ability to our work, but our genius to our life! ___ 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] Potential bugs when generating ALPHA_FS with ruby
Actually, I intended to configure a ruby memory hierarchy with a mesh topology and full system support. I had no problem building build/ALPHA_SE_MOESI_CMP_directory/m5.opt at all. But if I run build/ALPHA_SE_MOESI_CMP_directory/m5.opt -re tests/run.py tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory -n 4 --topology=Mesh --mesh-rows=2, I would get the error of assert(node.type == 'DMA_Controller'). I guess it might be due to that the FS model has the DMA module but SE model doesn't, since it is required that a DMA controller be attached to the node 0 in the mesh topology. So I tried to configure a ruby memory hierarchy with a mesh topology and FS support, and then I got the problems as described in previous emails. Sorry for posting the messages on m5-dev. Next time I will send my questions about the devel version of M5 on m5-users. Thanks, Leonard On Tue, Jan 11, 2011 at 11:00 PM, Gabe Black gbl...@eecs.umich.edu wrote: We should be discussing this on m5-users, and it's probably better to set those parameters on the scons command line than in the file with the default settings. If you run scons --help, or scons --help build/ALPHA_SE_MOESI_CMP_directory/m5.opt in this case, it will print out what setting it's using for those variables. The file you're modifying is for the default values, and once those are in use I don't know exactly what you need to do to get them to be read in again. Gabe On 01/11/11 21:02, Sage wrote: Hi, Korey, Thanks for your reply. But even after I removed “InOrderCPU” from the CPU_MODELS list and cleaned up the build folder, source files related to the inorder model would still be compiled and the same errors would show up again. Thanks, Leonard On Tue, Jan 11, 2011 at 10:36 PM, Korey Sewell ksew...@umich.edu wrote: I'll check those errors out for you, but InOrder doesnt currently work in FS mode, so you would be OK to remove that from your build options if you so chose. On Tue, Jan 11, 2011 at 11:14 PM, Sage leonard...@gmail.com wrote: Hello, everyone, In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory by just changing the ALPHA_SE_MOESI_CMP_directory to the following script. FULL_SYSTEM = 1 SS_COMPATIBLE_FP = 1 CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU' PROTOCOL = 'MOESI_CMP_directory' RUBY = True But I got the errors as follows when building it, which I believe indicates certain bugs. build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc: In member function 'void InOrderCPU::processInterrupts(Fault)': build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected type-specifier before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: conversion from 'int*' to non-scalar type 'ThePipeline::DynInstPtr' requested build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:633: error: expected ',' or ';' before 'Impl' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.cc:634: error: no matching function for call to 'InOrderCPU::trap(Fault, ThePipeline::DynInstPtr)' build/ALPHA_FS_MOESI_CMP_directory/cpu/inorder/cpu.hh:344: note: candidates are: void InOrderCPU::trap(Fault, ThreadID, ThePipeline::DynInstPtr, int) In line 633 of src/cpu/inorder/cpu.cc, it complains that Impl::DynInst is not a correct class name. The problem couldn't be worked around by removing Impl::. In line 634 of the same file, only two variables are passed to the trap function but apparently it needs another ThreadID type variable. Since I am not quite familiar with the source code in the cpu folder, I just raise my questions on the errors and hope someone can fix it. Thanks, Leonard -- Give our ability to our work, but our genius to our life! ___ 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 -- Give our ability to our work, but our genius to our life! ___ m5-dev mailing listm5-...@m5sim.orghttp://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- Give our ability to our work, but our genius to our life! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
