Re: [gem5-dev] Review Request: [mq]: FunctionalAccess.9.patch
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-12 14:55:00.907885) Review request for Default. Summary (updated) --- [mq]: FunctionalAccess.9.patch Diffs (updated) - configs/example/ruby_direct_test.py ac4da9f8ea80 configs/example/ruby_fs.py ac4da9f8ea80 configs/example/ruby_mem_test.py ac4da9f8ea80 configs/example/ruby_network_test.py ac4da9f8ea80 configs/example/ruby_random_test.py ac4da9f8ea80 configs/ruby/MESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MI_example.py ac4da9f8ea80 configs/ruby/MOESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MOESI_CMP_token.py ac4da9f8ea80 configs/ruby/MOESI_hammer.py ac4da9f8ea80 configs/ruby/Ruby.py ac4da9f8ea80 src/cpu/testers/memtest/memtest.hh ac4da9f8ea80 src/cpu/testers/memtest/memtest.cc ac4da9f8ea80 src/mem/packet.hh ac4da9f8ea80 src/mem/packet.cc ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L1cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L2cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-dir.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-dir.sm ac4da9f8ea80 src/mem/ruby/network/Network.cc ac4da9f8ea80 src/mem/ruby/network/Network.py ac4da9f8ea80 src/mem/ruby/profiler/Profiler.cc ac4da9f8ea80 src/mem/ruby/profiler/Profiler.py ac4da9f8ea80 src/mem/ruby/recorder/Tracer.cc ac4da9f8ea80 src/mem/ruby/recorder/Tracer.py ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.hh ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.cc PRE-CREATION src/mem/ruby/slicc_interface/Controller.py ac4da9f8ea80 src/mem/ruby/slicc_interface/SConscript ac4da9f8ea80 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py ac4da9f8ea80 src/mem/ruby/system/CacheMemory.hh ac4da9f8ea80 src/mem/ruby/system/CacheMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.hh ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.py ac4da9f8ea80 src/mem/ruby/system/RubyPort.hh ac4da9f8ea80 src/mem/ruby/system/RubyPort.cc ac4da9f8ea80 src/mem/ruby/system/RubySystem.py ac4da9f8ea80 src/mem/ruby/system/SConscript ac4da9f8ea80 src/mem/ruby/system/Sequencer.py ac4da9f8ea80 src/mem/ruby/system/System.hh ac4da9f8ea80 src/mem/ruby/system/System.cc ac4da9f8ea80 src/mem/slicc/ast/MemberExprAST.py ac4da9f8ea80 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-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-06-12 14:55:53.667339) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch. The patch has been tested for MI, MOESI directory, MOESI hammer and MESI directory protocols. It seems that MOESI token protocol cannot support functional accesses with it current implementation, there seems to be some problem with the L2 cache controller. Diffs (updated) - configs/example/ruby_direct_test.py ac4da9f8ea80 configs/example/ruby_fs.py ac4da9f8ea80 configs/example/ruby_mem_test.py ac4da9f8ea80 configs/example/ruby_network_test.py ac4da9f8ea80 configs/example/ruby_random_test.py ac4da9f8ea80 configs/ruby/MESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MI_example.py ac4da9f8ea80 configs/ruby/MOESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MOESI_CMP_token.py ac4da9f8ea80 configs/ruby/MOESI_hammer.py ac4da9f8ea80 configs/ruby/Ruby.py ac4da9f8ea80 src/cpu/testers/memtest/memtest.hh ac4da9f8ea80 src/cpu/testers/memtest/memtest.cc ac4da9f8ea80 src/mem/packet.hh ac4da9f8ea80 src/mem/packet.cc ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L1cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L2cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-dir.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-dir.sm ac4da9f8ea80 src/mem/ruby/network/Network.cc ac4da9f8ea80 src/mem/ruby/network/Network.py ac4da9f8ea80 src/mem/ruby/profiler/Profiler.cc ac4da9f8ea80 src/mem/ruby/profiler/Profiler.py ac4da9f8ea80 src/mem/ruby/recorder/Tracer.cc ac4da9f8ea80 src/mem/ruby/recorder/Tracer.py ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.hh ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.cc PRE-CREATION src/mem/ruby/slicc_interface/Controller.py ac4da9f8ea80 src/mem/ruby/slicc_interface/SConscript ac4da9f8ea80 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py ac4da9f8ea80 src/mem/ruby/system/CacheMemory.hh ac4da9f8ea80 src/mem/ruby/system/CacheMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.hh ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.py ac4da9f8ea80 src/mem/ruby/system/RubyPort.hh ac4da9f8ea80 src/mem/ruby/system/RubyPort.cc ac4da9f8ea80 src/mem/ruby/system/RubySystem.py ac4da9f8ea80 src/mem/ruby/system/SConscript ac4da9f8ea80 src/mem/ruby/system/Sequencer.py ac4da9f8ea80 src/mem/ruby/system/System.hh ac4da9f8ea80 src/mem/ruby/system/System.cc ac4da9f8ea80 src/mem/slicc/ast/MemberExprAST.py ac4da9f8ea80 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Ruby: Token Coherence and Functional Access
Brad, in the token coherence protocol, the l2 cache controller moves from state O to I and sends data to the memory. I think this particular transition is may pose a problem in enabling functional accesses for the protocol. The problem, I think, is that both the directory and the cache controller are in stable states even though there is data travelling in the network. This means that both the controllers will allow a functional write to go ahead. But then the data will be over written by the value sent from the l2 controller to the directory controller. My understanding of the protocol implementation is close to \epsilon. I think this is what I observed today in the morning. Do think this understanding is correct? -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Korey, try 'hg status'. It would list the set of files that are not being tracked. May be there is some file that should be committed and has not been. -- Nilay On Thu, 9 Jun 2011, Korey Sewell wrote: My local repo has this at the tip: hg tip changeset: 8342:77d12d8f7971 tag: tip user:Korey Sewell ksew...@umich.edu date:Thu Jun 09 01:34:06 2011 -0400 summary: sparc: compilation fixes for inorder and the hg outgoing tab says nothing outstanding. I have not tried this on zizzer yet, but that is the next step. On Thu, Jun 9, 2011 at 6:02 PM, Steve Reinhardt ste...@gmail.com wrote: It fails for me... are you sure you've pushed everything? Have you tried it on zizzer? Steve On Thu, Jun 9, 2011 at 1:36 PM, Korey Sewell ksew...@umich.edu wrote: ok, this is a bit wierd. I'm running all the tests locally and they are passing ... Even the O3 one: build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp On Thu, Jun 9, 2011 at 1:52 PM, Korey Sewell ksew...@umich.edu wrote: Yup, that's me. I will update the stats for the simple cpus. I thought I had caught the branchTarget() error before, but apparently not. On Thu, Jun 9, 2011 at 1:45 PM, Steve Reinhardt ste...@gmail.com wrote: Looks like all the SPARC tests failed. The two o3-timing ones have this error: panic: StaticInst::branchTarget() called on instruction that is not a PC-relative branch. [branchTarget:build/SPARC_SE/cpu/static_inst.cc, line 99] The others seem to have run correctly, but have stats differences like this: system.cpu.num_conditional_control_insts 0774 774 +.00% system.cpu.num_func_calls 0146146 +.00% I'm guessing this is from Korey's recent SPARC change... Steve ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The
main function should look like --
int main()
{
B* b = new B();
A* a = b;
a-function();
return 0;
}
Now what would happen?
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a-function();
return 0;
}
Now what would happen?
This compiles. However, if you do b-function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though
function() is private for class B, still it gets invoked using the pointer
from class A. I was not aware of this before.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a-function();
return 0;
}
Now what would happen?
This compiles. However, if you do b-function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though function()
is private for class B, still it gets invoked using the pointer from class A. I
was not aware of this before.
Overriding and access visibility is orthogonal, you use class A pointer to
access its public function.
I won't term this is a overriding, the function that will be called would
be the one defined in class B, as 'function()' is a virtual member of
class A. But then, 'function()' is private to class B, so I would expect
some error to occur. I think the reason is that visibility is tested only
at compile time and never at run time.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
On 2011-06-08 17:11:26, Brad Beckmann wrote: This looks fine to me. I assume that if a controller doesn't include a setPermission or getPermission function, the compiler error message is the same as when a controller doesn't specify a getState function. Correct? Currently SLICC does not output any error if set/getState() or set/getAccessPermission() are missing. But I have patch in the queue which enables catching these errors in SLICC. For now GCC outputs that a particular function has not been implemented. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/#review1301 --- On 2011-06-06 14:45:22, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-06-06 14:45:22) Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. get and set functions for access permissions have been added to the Controller state machine. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. NOTE: Each protocol will have to define these get and set functions in order to compile successfully. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Passes regression tests and 1 loads with ruby random tester. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: Ruby: Correctly set access permissions for di...
changeset 30daf1dd5c91 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30daf1dd5c91
description:
Ruby: Correctly set access permissions for directory entries
The access permissions for the directory entries are not being set
correctly.
This is because pointers are not used for handling directory entries.
function. get and set functions for access permissions have been added
to the
Controller state machine. The changePermission() function provided by
the
AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC
code once again. The set_permission() functionality has been removed.
NOTE: Each protocol will have to define these get and set functions in
order
to compile successfully.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 20
src/mem/protocol/MESI_CMP_directory-L2cache.sm | 21 -
src/mem/protocol/MESI_CMP_directory-dir.sm | 15 ++-
src/mem/protocol/MESI_CMP_directory-dma.sm | 7 +++
src/mem/protocol/MI_example-cache.sm | 20
src/mem/protocol/MI_example-dir.sm | 15 +++
src/mem/protocol/MI_example-dma.sm | 7 +++
src/mem/protocol/MOESI_CMP_directory-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-L2cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-dir.sm| 14 ++
src/mem/protocol/MOESI_CMP_directory-dma.sm| 7 +++
src/mem/protocol/MOESI_CMP_token-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_token-L2cache.sm| 15 +++
src/mem/protocol/MOESI_CMP_token-dir.sm| 15 ++-
src/mem/protocol/MOESI_CMP_token-dma.sm| 7 +++
src/mem/protocol/MOESI_hammer-cache.sm | 20
src/mem/protocol/MOESI_hammer-dir.sm | 15 ++-
src/mem/protocol/MOESI_hammer-dma.sm | 7 +++
src/mem/protocol/Network_test-cache.sm | 7 +++
src/mem/protocol/Network_test-dir.sm | 7 +++
src/mem/protocol/RubySlicc_Types.sm| 8 ++--
src/mem/ruby/slicc_interface/AbstractController.hh | 4
src/mem/slicc/ast/MethodCallExprAST.py | 8 +++-
src/mem/slicc/symbols/StateMachine.py | 17 -
24 files changed, 296 insertions(+), 20 deletions(-)
diffs (truncated from 604 to 300 lines):
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 11:58:09
2011 -0500
@@ -183,6 +183,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L1_TBEs[addr];
+if(is_valid(tbe)) {
+ return L1Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L1Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L1Cache_State_to_permission(state));
+}
+ }
+
Event mandatory_request_type_to_event(RubyRequestType type) {
if (type == RubyRequestType:LD) {
return Event:Load;
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 11:58:09
2011 -0500
@@ -202,7 +202,6 @@
return L2Cache_State_to_string(getState(tbe, cache_entry, addr));
}
- // when is this called
void setState(TBE tbe, Entry cache_entry, Address addr, State state) {
// MUST CHANGE
@@ -215,6 +214,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L2_TBEs[addr];
+if(is_valid(tbe)) {
+ return L2Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L2Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L2Cache_State_to_permission(state));
+}
+ }
+
Event L1Cache_request_type_to_event(CoherenceRequestType type, Address addr,
MachineID requestor, Entry cache_entry) {
if(type == CoherenceRequestType:GETS) {
diff -r e39a9c0493ad -r 30daf1dd5c91
[gem5-dev] Query on inheritance and virtual functions
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-06-06 14:44:19.791924) Review request for Default. Summary (updated) --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. get and set functions for access permissions have been added to the Controller state machine. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. NOTE: Each protocol will have to define these get and set functions in order to compile successfully. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-06-06 14:45:22.384167) Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. get and set functions for access permissions have been added to the Controller state machine. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. NOTE: Each protocol will have to define these get and set functions in order to compile successfully. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 Diff: http://reviews.m5sim.org/r/684/diff Testing (updated) --- Passes regression tests and 1 loads with ruby random tester. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] /z/m5/regression/do-regression --scratch all
We again had the same problem as yesterday, though it seems that all the regression tests run up to completion. Any suggestions on resolving this? scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x11353bd8) in state executed -- Nilay On Sun, 5 Jun 2011, m5test wrote: scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/long/50.vortex/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/opt/long/40.perlbmk/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/60.bzip2/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/long/30.eon/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/50.vortex/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/long/70.twolf/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/long/50.vortex/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/long/00.gzip/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/70.twolf/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/long/70.twolf/alpha/tru64/inorder-timing passed. * build/ALPHA_SE/tests/opt/long/30.eon/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/long/70.twolf/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/00.gzip/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/long/30.eon/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/long/00.gzip/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/50.vortex/alpha/tru64/inorder-timing passed. * build/ALPHA_SE/tests/opt/long/60.bzip2/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/long/40.perlbmk/alpha/tru64/simple-timing passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. *
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Does any one has any idea what a dependency cycles is? This is what zizzer's log has. scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/ALPHA_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x412a680) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x410d200) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0x128d1290) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0xdf2db48) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x11ccb4d0) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x30ae9b90) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x9b5d518) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x128ce9e0) in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x16ea8560) in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x3a89d518) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x4105ef0) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x128ac710) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0x11ff1320) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x30be19e0) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x34b024d0) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x34cfcc20) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x128a8440) in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x3a7b16c8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x9b58248) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x8f27fc8) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x34b08ef0) in state up_to_date Internal Error: no cycle found for node build/SPARC_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x2c1b0f38) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x11fefa70) in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x16ec7290) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0xdf2d2d8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x8f1dcf8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x9b7d7e8) in state up_to_date -- Nilay On Sat, 4 Jun 2011, Cron Daemon wrote: scons: *** Found dependency cycle(s): * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby
Re: [gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
Will clearing all the existing builds and starting afresh remove this issue? Can some one do this? -- Nilay On Sat, 4 Jun 2011, Steve Reinhardt wrote: It seems very strange... like at a high level it thinks there's a cycle, but when it goes to print out where it is it can't find one. I've never seen this myself; I wonder if it's a bug in the version of scons on zizzer (v0.98), as the machine I use has v.1.2.0. It is a little strange that we're building params structs for Ruby objects in ALPHA_SE though. Steve On Sat, Jun 4, 2011 at 6:41 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Does any one has any idea what a dependency cycles is? This is what zizzer's log has. scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/ALPHA_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x412a680) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x410d200) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0x128d1290) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0xdf2db48) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x11ccb4d0) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x30ae9b90) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x9b5d518) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x128ce9e0) in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x16ea8560) in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x3a89d518) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x4105ef0) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x128ac710) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L2Cache_Controller.hh (SCons.Node.FS.File instance at 0x11ff1320) in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x30be19e0) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x34b024d0) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x34cfcc20) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x128a8440) in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x3a7b16c8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x9b58248) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x8f27fc8) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x34b08ef0) in state up_to_date Internal Error: no cycle found for node build/SPARC_FS/params/Directory_Controller.hh (SCons.Node.FS.File instance at 0x2c1b0f38) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x11fefa70) in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x16ec7290) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0xdf2d2d8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/DMA_Controller.hh (SCons.Node.FS.File instance at 0x8f1dcf8) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/L1Cache_Controller.hh (SCons.Node.FS.File instance at 0x9b7d7e8) in state up_to_date -- Nilay
[gem5-dev] changeset in m5: SLICC: Remove machine name as prefix to functions
changeset b9ba22cb23f2 in /z/repo/m5
details: http://repo.gem5.org/m5?cmd=changeset;node=b9ba22cb23f2
description:
SLICC: Remove machine name as prefix to functions
Currently, the machine name is appended before any of the functions
defined with in the sm files. This is not necessary and it also
means that these functions cannot be used outside the sm files.
This patch does away with the prefixes. Note that the generated
C++ files in which the code for these functions is present are
still named such that the machine name is the prefix.
diffstat:
src/mem/slicc/symbols/Func.py | 14 +++---
src/mem/slicc/symbols/StateMachine.py | 16
2 files changed, 15 insertions(+), 15 deletions(-)
diffs (74 lines):
diff -r 3a2aebf01bf3 -r b9ba22cb23f2 src/mem/slicc/symbols/Func.py
--- a/src/mem/slicc/symbols/Func.py Thu Jun 02 21:23:02 2011 -0700
+++ b/src/mem/slicc/symbols/Func.py Fri Jun 03 13:52:18 2011 -0500
@@ -37,15 +37,12 @@
self.param_strings = param_strings
self.body = body
self.isInternalMachineFunc = False
+self.c_ident = ident
-if machine is None:
-self.c_ident = ident
-elif external in self or primitive in self:
-self.c_ident = ident
+if machine is None or external in self or primitive in self:
+pass
else:
self.machineStr = str(machine)
-# Append with machine name
-self.c_ident = %s_%s % (self.machineStr, ident)
self.isInternalMachineFunc = True
def __repr__(self):
@@ -107,6 +104,9 @@
${{self.body}}
}
''')
-code.write(path, %s.cc % self.c_ident)
+if self.isInternalMachineFunc:
+code.write(path, %s_%s.cc % (self.machineStr,self.c_ident))
+else:
+code.write(path, %s.cc % self.c_ident)
__all__ = [ Func ]
diff -r 3a2aebf01bf3 -r b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Thu Jun 02 21:23:02 2011 -0700
+++ b/src/mem/slicc/symbols/StateMachine.py Fri Jun 03 13:52:18 2011 -0500
@@ -1071,13 +1071,13 @@
{
''')
if self.TBEType != None and self.EntryType != None:
-code('${ident}_State state = ${ident}_getState(m_tbe_ptr,
m_cache_entry_ptr, addr);')
+code('${ident}_State state = getState(m_tbe_ptr,
m_cache_entry_ptr, addr);')
elif self.TBEType != None:
-code('${ident}_State state = ${ident}_getState(m_tbe_ptr, addr);')
+code('${ident}_State state = getState(m_tbe_ptr, addr);')
elif self.EntryType != None:
-code('${ident}_State state = ${ident}_getState(m_cache_entry_ptr,
addr);')
+code('${ident}_State state = getState(m_cache_entry_ptr, addr);')
else:
-code('${ident}_State state = ${ident}_getState(addr);')
+code('${ident}_State state = getState(addr);')
code('''
${ident}_State next_state = state;
@@ -1115,15 +1115,15 @@
CLEAR_TRANSITION_COMMENT();
''')
if self.TBEType != None and self.EntryType != None:
-code('${ident}_setState(m_tbe_ptr, m_cache_entry_ptr, addr,
next_state);')
+code('setState(m_tbe_ptr, m_cache_entry_ptr, addr, next_state);')
code('set_permission(m_cache_entry_ptr,
${ident}_State_to_permission(next_state));')
elif self.TBEType != None:
-code('${ident}_setState(m_tbe_ptr, addr, next_state);')
+code('setState(m_tbe_ptr, addr, next_state);')
elif self.EntryType != None:
-code('${ident}_setState(m_cache_entry_ptr, addr, next_state);')
+code('setState(m_cache_entry_ptr, addr, next_state);')
code('set_permission(m_cache_entry_ptr,
${ident}_State_to_permission(next_state));')
else:
-code('${ident}_setState(addr, next_state);')
+code('setState(addr, next_state);')
code('''
} else if (result == TransitionResult_ResourceStall) {
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-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-06-01 18:59:16.473427) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns busy which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs (updated) - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-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-06-01 18:59:39.117342) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns busy which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing (updated) --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request: SLICC: Add a check function for State Machine
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/723/ --- Review request for Default. Summary --- SLICC: Add a check function for State Machine This patch adds a function for State Machines that will check whether the provided description in the .sm files includes some of the required functions, like getState() and setState(). Diffs - src/mem/slicc/ast/MachineAST.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/723/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses
I had posted a review request, it is not appropriate to respond to it with these type of questions. These questions should be asked on gem5-users list. And now the answer to your question. We currently do not update GEMS code. And I do not think that there is any plan to do so in future. In fact, we advise users to move to gem5. -- Nilay On Thu, 2 Jun 2011, huangyongbing wrote: Hi. I am currently using GEMS and Simics. So I care about whether the corresponding codes are also updated in GEMS. -Yongbing Huang 发件人： Nilay Vaish 发送时间： 2011-06-02 09:57:40 收件人： Nilay Vaish; Default; Brad Beckmann; Steve Reinhardt; Gabe Black 抄送： 主题： Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-01 18:59:16.473427) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns busy which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs (updated) - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org
Re: [gem5-dev] Functional Memory Accesses in Ruby
On Sat, 28 May 2011, Nilay Vaish wrote: Hi Brad I am trying to complete the patch on functional accesses in Ruby. I came across this problem while testing the patch for higher number of processors. I am working with MESI CMP directory protocol right now. So I will describe the problem in its context. Assume we are trying to functionally write some thing to block A. It is in state S_I in the L2 cache. When a block moves to state S_I from state SS, then the cache block in the cache is deallocated. Therefore, when viewed from the CacheMemory's perpespective, since the cache does not have block A, therefore, the L2 cache is of no consequence for this access. But the controller has a TBE for this block. And this TBE will have this block with AccessPermission:Busy. Also, there are L1 caches in the system that hold this block in S state. Now, as per the current condition for write functional accesses, if((num_busy == 0 num_ro 0) || num_rw == 1) this access would go ahead as num_busy would evaluate to 0 and num_ro would evaluate to some value greater than 0. But clearly we do not want this access to be performed since that state S_I is a busy state and no other cache holds the block in a read-write state. It seems to me that the controller should supply the function for deciding the access permissions, since it is possible that one the TBE holds the block. -- Nilay Brad, I went over the discussion that we had this morning. I think the getState() function cannot be used for extracting access permissions. This is because the getState() function needs pouinters to transaction buffer and cache entries, apart from the address. I think we should let the Controller provide a function for getting the access permissions. This function would be a virtual function declared in the AbstractController class, but would not be pure. The AbstractController implementation of the function would always return busy, so that functional accesses are not enabled at all for protocols that do not provide such a function. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Functional Memory Accesses in Ruby
Hi Brad I am trying to complete the patch on functional accesses in Ruby. I came across this problem while testing the patch for higher number of processors. I am working with MESI CMP directory protocol right now. So I will describe the problem in its context. Assume we are trying to functionally write some thing to block A. It is in state S_I in the L2 cache. When a block moves to state S_I from state SS, then the cache block in the cache is deallocated. Therefore, when viewed from the CacheMemory's perpespective, since the cache does not have block A, therefore, the L2 cache is of no consequence for this access. But the controller has a TBE for this block. And this TBE will have this block with AccessPermission:Busy. Also, there are L1 caches in the system that hold this block in S state. Now, as per the current condition for write functional accesses, if((num_busy == 0 num_ro 0) || num_rw == 1) this access would go ahead as num_busy would evaluate to 0 and num_ro would evaluate to some value greater than 0. But clearly we do not want this access to be performed since that state S_I is a busy state and no other cache holds the block in a read-write state. It seems to me that the controller should supply the function for deciding the access permissions, since it is possible that one the TBE holds the block. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-05-27 11:41:44.345753) Review request for Default. Summary (updated) --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. The patch has been updated to set permissions for all the five protocols. All the protocols compile and clears 1 loads. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MI_example-cache.sm dda2a88eb7c4 src/mem/protocol/MI_example-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-dir.sm dda2a88eb7c4 src/mem/protocol/RubySlicc_Types.sm dda2a88eb7c4 src/mem/slicc/ast/MethodCallExprAST.py dda2a88eb7c4 src/mem/slicc/symbols/StateMachine.py dda2a88eb7c4 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
On Fri, 6 May 2011, Beckmann, Brad wrote: Hi Nilay, Yeah, pulling the State into the Machine makes sense to me. If I recall, my previous patch made it necessary that each machine included a state_declaration (previously the state enum). More tightly integrating the state to the machine seems to be a natural progression on that path. I understand moving the permission settings back to setState is the easiest way to make this work. However, it would be great if we could combine the setting of state and the setting of permission into one function call from the sm file. Thus we don't have to worry about the situation where one sets the state, but forgets to set the permission. That could lead to some random functional access failing and a very painful debug. Brad I was trying to recall why I had suggested pulling State in to the Machine. It seems the reasoning was that then the calls to the function *_State_to_Permission() can be shortened to State_to_Permission(). The problem with combining the setting state and the permission it seems would be that cache and directory entries are treated differently. Cache entries get supplied to set state as pointers, where as directory entries are sought within the function it self. I am currently in favor of going with what I submitted earlier so that functional access patch can get out of the way soon as possible. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[m5-dev] changeset in m5: Trace: Remove the options trace-help and trace-...
changeset a6363c870af6 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=a6363c870af6 description: Trace: Remove the options trace-help and trace-flags The options trace-help and trace-flags are no longer required. In there place, the options debug-help and debug-flags have been provided. diffstat: src/python/m5/main.py | 4 1 files changed, 0 insertions(+), 4 deletions(-) diffs (14 lines): diff -r 3c628a51f6e1 -r a6363c870af6 src/python/m5/main.py --- a/src/python/m5/main.py Fri May 06 01:00:32 2011 -0700 +++ b/src/python/m5/main.py Sat May 07 07:38:36 2011 -0500 @@ -106,10 +106,6 @@ # Tracing options group(Trace Options) -option(--trace-help, action='store_true', -help=Print help on trace flags) -option(--trace-flags, metavar=FLAG[,FLAG], action='append', split=',', -help=Sets the flags for tracing (-FLAG disables a flag)) option(--trace-start, metavar=TIME, type='int', help=Start tracing at TIME (must be in ticks)) option(--trace-file, metavar=FILE, default=cout, ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [m5-users] Tracing does not work
Joel, I have pushed in the patch the removes the options trace-help and trace-flags. But trace-start and trace-file work as before. You can use them in conjunction with debug-flags. -- Nilay On Fri, 6 May 2011, Nilay Vaish wrote: I was thinking og doing it since Nate is not around. I'll do it soon. -- Nilay On Fri, 6 May 2011, Joel Hestness wrote: Hey Nilay, It looks like the tracing (debug) functionality is now working again, but the M5 help message is still incorrect (and extremely misleading). For instance, trace-flags, and trace-file are still accepted, but they don't do anything now. They should be eliminated from the message. We're also missing the equivalent of trace-start and trace-file. Do you mind cleaning that up? Thanks, Joel PS. I haven't followed the tracing/debugging thread closely enough, but it seems like trace and debug should be different things (though they are currently implemented as the same thing). Is there a reason why we moved over to debug? ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
Korey, I don't think there will be any change in the simulation performance. I am not sure about stats. Brad, were the stats updated after you made the change? -- Nilay On Fri, 6 May 2011, Korey Sewell wrote: Nilay, can you explain the impact of that bug in terms of simulation performance? Are benchmarks running slower because of this change? Will regressions need to be updated? On Fri, May 6, 2011 at 8:13 PM, Beckmann, Brad brad.beckm...@amd.comwrote: Hi Nilay, Yeah, pulling the State into the Machine makes sense to me. If I recall, my previous patch made it necessary that each machine included a state_declaration (previously the state enum). More tightly integrating the state to the machine seems to be a natural progression on that path. I understand moving the permission settings back to setState is the easiest way to make this work. However, it would be great if we could combine the setting of state and the setting of permission into one function call from the sm file. Thus we don't have to worry about the situation where one sets the state, but forgets to set the permission. That could lead to some random functional access failing and a very painful debug. Brad ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Adding m5 debug statements to SLICC
Koreay, DPRINTF already works in sm files. Use RubySlicc as the flag. You can also use error() and assert() functions which have the following prototypes -- void error(std::string msg); void assert(bool condition); -- Nilay On Fri, 6 May 2011, Korey Sewell wrote: I guess I should rephrase this question to this: What's the best way to expose a new function to be used in the *.sm SLICC files? On Fri, May 6, 2011 at 3:26 AM, Korey Sewell ksew...@umich.edu wrote: Hi all, I'm trying to drop in warn/inform/panic/dprintf/etc messages into the SLICC files because these functions are pretty invaluable to the being able to validate, debug and document what's going on in your simulation, but I have not been able to get them to work inside a SLICC .sm file. I was hoping that I could place a base/misc.hh header file somewhere and magic would ensue but that was not the case :) Instead, it looks like I would have to add my own detection functions for warn/inform/etc. in the SLICC parser, so that when I call those functions in the code, it will recognize it. I am wondering if anyone has had a similar problem like this (in terms of adding random C++ code to a *.sm file) and if so can you give me your perspective on what I would need to do get this working in SLICC. Is this functionality already there in SLICC and I'm just missing something? The current error I receive is this: Exception: MOESI_CMP_directory-L2cache.sm:973: Error: Unrecognized function name: 'warn': File /y/ksewell/m5-dev/m5-outgoing/SConstruct, line 1025: ... File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/ast/AST.py, line 50: self.location.error(message, *args) File /y/ksewell/m5-dev/m5-incoming/src/mem/slicc/util.py, line 72: raise Exception, %s: Error: %s % (self, message) I think this is pretty high utility, so if it's not going to be a programming adventure, I'd like to go ahead and spend time to get it working. If anyone has any thoughts or suggestions, please let me know what you think. Thanks. -- - Korey -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [m5-users] Tracing does not work
I was thinking og doing it since Nate is not around. I'll do it soon. -- Nilay On Fri, 6 May 2011, Joel Hestness wrote: Hey Nilay, It looks like the tracing (debug) functionality is now working again, but the M5 help message is still incorrect (and extremely misleading). For instance, trace-flags, and trace-file are still accepted, but they don't do anything now. They should be eliminated from the message. We're also missing the equivalent of trace-start and trace-file. Do you mind cleaning that up? Thanks, Joel PS. I haven't followed the tracing/debugging thread closely enough, but it seems like trace and debug should be different things (though they are currently implemented as the same thing). Is there a reason why we moved over to debug? ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. I have done this only for the MESI protocol so far. Once we build a consensus one the changes, I will make changes to other protocols as well. As far as testing is concerned, the protocol compiles and clears 1 loads. I did not test any more than that. A point that I wanted to raise for discussion: I think we should pull State enum and the accompanying functions into the Machine it self. Brad, what do you think? Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-L2cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-dir.sm 3c628a51f6e1 src/mem/protocol/RubySlicc_Types.sm 3c628a51f6e1 src/mem/slicc/ast/MethodCallExprAST.py 3c628a51f6e1 src/mem/slicc/symbols/StateMachine.py 3c628a51f6e1 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Error while compiling (changeset 8229)
I am trying to compile m5 and the scons exits with errors. Following is the compilation command -- scons -j 12 CXX=g++44 CC=gcc44 USE_MYSQL=False RUBY=True build/ALPHA_SE_MESI_CMP_directory/m5.fast and errors In file included from build/ALPHA_SE_MESI_CMP_directory/python/swig/stats_wrap.cc:3163: build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:52: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:63: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:73: error: 'size_type' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:75: error: 'size_type' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:81: error: 'uint64_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:83: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:156: error: ISO C++ forbids declaration of 'DistData' with no type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:156: error: expected ',' or '...' before '' token The command works till changeset 8228. It fails on 8229, the one on sorting included files. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Error while compiling (changeset 8229)
Nate, since I have provided the option USE_MYSQL=False, why should mysql.hh even come in to picture? -- Nilay On Wed, 20 Apr 2011, nathan binkert wrote: The solution is to #include base/types.hh in mysql.hh, but to be honest, I'm not sure how this is even happening. Perhaps you need to blow away your build directory and compile again. That said, I did not compile with USE_MYSQL=False, so this could just be a bug that shows up in that instance. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Testing Ruby Memory Controller
Is there a tester for testing the functionality of Ruby's memory controller? Thanks 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
On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141 Why are you adding this function? SLICC already generates a similar function: getPermission(). Overall, I hope/think we can add functional access support without requiring any more changes to the protocol specific .sm files beyond the changeset: 8086:bf0335d98250 that I checked in a couple months ago. Nilay Vaish wrote: How would you use the function that is generated by SLICC inside the sm file? I am concerned about the visibility of the function. Brad Beckmann wrote: You can certainly use a function that is generated by SLICC inside the sm file. The 'trigger' function is one such example. However, I'm not clear why you need to do that? Specifically, why do you need to explicitly set the permissions in the getCacheEntry function? I beleive the controller's doTransition function already does that when a transition successfully completes. Nilay Vaish wrote: I checked the generated code. It seems that permissions are being set only for the cache entries and not for the directory entries. Brad Beckmann wrote: Really? You should see a call to set_permissions inside the Directory_Transitions.cc file. For example, when I compile the MOESI_hammer protocol, I see the set_permission call on line 51 in Directory_Transitions.cc. Nilay Vaish wrote: The permissions would be set for the probe filter entry and not for the directory entry. The directory entry pointer is not passed around like the cache entry or TBE pointer. Brad Beckmann wrote: Doh! Yep, that is a problem. So what are the potential solutions: 1. Inside the setState functions for the DirectoryControllers, we also call set_permission. This would require us to expose set_permissions to SLICC similar to how trigger is exposed to SLICC. Certainly possilbe, but not ideal. Especially because it will require directory controllers and cache controllers to have different functionality in their setState functions. 2. Instead of allowing an entry's state to be directly assigned in the setState functions, make the state variable private, thus requiring a public funciton to modify state. When SLICC generates the implementation of that public function, have that function modify both the state and the permissions. 3. Remove the m_permission field in all entries and just rely on get_permission to return the current permissions for cache and directory entries. I'm not sure how to do that unless we create an AbstractState class so that the state can be accessed by the Ruby side. Do we want to make such a change? If we can make it work, I would prefer the second solution. What do you think? Do you see other potential solutions? If you agree that the second solution is best, do you want to take a crack at it or would you like me to? Since it is my patch that is broken, I feel responsible to fix it. However, I'm fine with you making the fix as well. I will think about it. IIRC, we had a discussion earlier as well whether setState() can be generated automatically by SLICC and we decided against it. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-13 14:29:01, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 14:29:01) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
On 2011-04-15 15:57:28, Steve Reinhardt wrote:
configs/example/ruby_mem_test.py, line 98
http://reviews.m5sim.org/r/611/diff/8/?file=11625#file11625line98
You probably don't want to commit this value, do you? If you want to
hardwire a number, I'd pick something more reasonable (somewhere between 10
and 25, just guessing).
I need to add a command line option for this. I can
put the default value as 10.
On 2011-04-15 15:57:28, Steve Reinhardt wrote:
src/mem/packet.hh, line 109
http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line109
I don't see much value in having separate error return codes for reads
and writes. I'd use a single code that ends in Error (like
FunctionalAccessError), and put it up a couple of lines with the other
Error codes.
I will make this change.
On 2011-04-15 15:57:28, Steve Reinhardt wrote:
src/mem/packet.hh, line 622
http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line622
Way too much code duplication here :-). I think this works, correct?
void
makeFunctionalResponse(bool success)
{
makeResponse();
if (!success) {
cmd = MemCmd::FunctionalAccessError;
}
}
Will make the required changes.
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1130
---
On 2011-04-13 14:29:01, Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/
---
(Updated 2011-04-13 14:29:01)
Review request for Default.
Summary
---
Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
Currently, the patch does not functional accesses for the PioPort.
Diffs
-
configs/example/ruby_mem_test.py 8b5f900233ee
configs/ruby/MESI_CMP_directory.py 8b5f900233ee
configs/ruby/Ruby.py 8b5f900233ee
src/cpu/testers/memtest/memtest.cc 8b5f900233ee
src/mem/packet.hh 8b5f900233ee
src/mem/packet.cc 8b5f900233ee
src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee
src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee
src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee
src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee
src/mem/ruby/network/Network.cc 8b5f900233ee
src/mem/ruby/network/Network.py 8b5f900233ee
src/mem/ruby/profiler/Profiler.cc 8b5f900233ee
src/mem/ruby/profiler/Profiler.py 8b5f900233ee
src/mem/ruby/recorder/Tracer.cc 8b5f900233ee
src/mem/ruby/recorder/Tracer.py 8b5f900233ee
src/mem/ruby/system/AbstractMemory.hh PRE-CREATION
src/mem/ruby/system/AbstractMemory.cc PRE-CREATION
src/mem/ruby/system/AbstractMemory.py PRE-CREATION
src/mem/ruby/system/Cache.py 8b5f900233ee
src/mem/ruby/system/CacheMemory.hh 8b5f900233ee
src/mem/ruby/system/CacheMemory.cc 8b5f900233ee
src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee
src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee
src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee
src/mem/ruby/system/RubyPort.hh 8b5f900233ee
src/mem/ruby/system/RubyPort.cc 8b5f900233ee
src/mem/ruby/system/RubySystem.py 8b5f900233ee
src/mem/ruby/system/SConscript 8b5f900233ee
src/mem/ruby/system/Sequencer.cc 8b5f900233ee
src/mem/ruby/system/Sequencer.py 8b5f900233ee
src/mem/ruby/system/System.hh 8b5f900233ee
src/mem/ruby/system/System.cc 8b5f900233ee
src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee
Diff: http://reviews.m5sim.org/r/611/diff
Testing
---
I have tested functional accesses with the ratio between functional
and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
10:90, 1:99. It is working in all the cases.
Thanks,
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Bug in changeset 8225 or 8227
Nate, it seems one of your checkins from yesterday has a bug. I receive the following message on executing any merculrial command. *** failed to import extension style from ./util/style.py: invalid syntax (file_types.py, line 143) -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Bug in changeset 8225 or 8227
On Sat, 16 Apr 2011, nathan binkert wrote: What version of python are you using? It could be that that syntax wasn't available until 2.5 and you're using something older. I can't do anything about it right now because I'm about to leave on a hike. Nate Nate, it seems one of your checkins from yesterday has a bug. I receive the following message on executing any merculrial command. *** failed to import extension style from ./util/style.py: invalid syntax (file_types.py, line 143) -- Nilay I am using python version 2.4.3. 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
On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141 Why are you adding this function? SLICC already generates a similar function: getPermission(). Overall, I hope/think we can add functional access support without requiring any more changes to the protocol specific .sm files beyond the changeset: 8086:bf0335d98250 that I checked in a couple months ago. Nilay Vaish wrote: How would you use the function that is generated by SLICC inside the sm file? I am concerned about the visibility of the function. Brad Beckmann wrote: You can certainly use a function that is generated by SLICC inside the sm file. The 'trigger' function is one such example. However, I'm not clear why you need to do that? Specifically, why do you need to explicitly set the permissions in the getCacheEntry function? I beleive the controller's doTransition function already does that when a transition successfully completes. Nilay Vaish wrote: I checked the generated code. It seems that permissions are being set only for the cache entries and not for the directory entries. Brad Beckmann wrote: Really? You should see a call to set_permissions inside the Directory_Transitions.cc file. For example, when I compile the MOESI_hammer protocol, I see the set_permission call on line 51 in Directory_Transitions.cc. The permissions would be set for the probe filter entry and not for the directory entry. The directory entry pointer is not passed around like the cache entry or TBE pointer. On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/ruby/system/CacheMemory.cc, line 270 http://reviews.m5sim.org/r/611/diff/6/?file=11563#file11563line270 Why are you commenting this line out? If you think it is no longer needed, just remove it. If we remove it, can we guarentee that the permission is initialized to some value? For instance, do we know whether the entry constructor will allows initialize the value? Nilay Vaish wrote: I expect the state to decide what the permission should be. Brad Beckmann wrote: However, if we don't set the permission to some later time, say at the end of a transition, what happens if we access the permission before then? Fine, I will uncomment the line. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-13 14:29:01, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 14:29:01) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 8b5f900233ee src/mem/ruby/system/CacheMemory.hh 8b5f900233ee src/mem/ruby/system/CacheMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee src/mem/ruby/system/RubyPort.hh 8b5f900233ee src/mem/ruby/system/RubyPort.cc 8b5f900233ee src/mem/ruby/system/RubySystem.py 8b5f900233ee src/mem/ruby/system/SConscript 8b5f900233ee src/mem/ruby/system/Sequencer.cc 8b5f900233ee src/mem/ruby/system/Sequencer.py 8b5f900233ee src/mem/ruby/system/System.hh 8b5f900233ee src/mem/ruby/system/System.cc 8b5f900233ee src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee Diff: http
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
Brad, can you elaborate on implementing functional accesses for the PioPort? -- Nilay On Wed, 13 Apr 2011, Beckmann, Brad wrote: I just reviewed it. Please let me know if you have any questions. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Tuesday, April 12, 2011 4:39 PM To: Default Subject: Re: [m5-dev] Review Request: Ruby: Add support for functional accesses Brad, can you take a look at the patch? I think we are now in position to implement functional accesses for the PioPort. -- 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
On 2011-04-13 13:43:26, Gabe Black wrote: Please fix these style issues, including the ones in this file I haven't explicitly pointed out. You should be using M5 style generally, but especially when your in M5 code. Also, please be sure to point this out to one of the classic memory system experts (Nate, Steve, or Ali) and get them to sign off. They might not see that this change touches outside of Ruby. Gabe, I made the changes that you had pointed. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1113 --- On 2011-04-13 14:29:01, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 14:29:01) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 8b5f900233ee src/mem/ruby/system/CacheMemory.hh 8b5f900233ee src/mem/ruby/system/CacheMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee src/mem/ruby/system/RubyPort.hh 8b5f900233ee src/mem/ruby/system/RubyPort.cc 8b5f900233ee src/mem/ruby/system/RubySystem.py 8b5f900233ee src/mem/ruby/system/SConscript 8b5f900233ee src/mem/ruby/system/Sequencer.cc 8b5f900233ee src/mem/ruby/system/Sequencer.py 8b5f900233ee src/mem/ruby/system/System.hh 8b5f900233ee src/mem/ruby/system/System.cc 8b5f900233ee src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, 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
On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141 Why are you adding this function? SLICC already generates a similar function: getPermission(). Overall, I hope/think we can add functional access support without requiring any more changes to the protocol specific .sm files beyond the changeset: 8086:bf0335d98250 that I checked in a couple months ago. Nilay Vaish wrote: How would you use the function that is generated by SLICC inside the sm file? I am concerned about the visibility of the function. Brad Beckmann wrote: You can certainly use a function that is generated by SLICC inside the sm file. The 'trigger' function is one such example. However, I'm not clear why you need to do that? Specifically, why do you need to explicitly set the permissions in the getCacheEntry function? I beleive the controller's doTransition function already does that when a transition successfully completes. I checked the generated code. It seems that permissions are being set only for the cache entries and not for the directory entries. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-13 14:29:01, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 14:29:01) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 8b5f900233ee src/mem/ruby/system/CacheMemory.hh 8b5f900233ee src/mem/ruby/system/CacheMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee src/mem/ruby/system/RubyPort.hh 8b5f900233ee src/mem/ruby/system/RubyPort.cc 8b5f900233ee src/mem/ruby/system/RubySystem.py 8b5f900233ee src/mem/ruby/system/SConscript 8b5f900233ee src/mem/ruby/system/Sequencer.cc 8b5f900233ee src/mem/ruby/system/Sequencer.py 8b5f900233ee src/mem/ruby/system/System.hh 8b5f900233ee src/mem/ruby/system/System.cc 8b5f900233ee src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, 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
On 2011-04-13 10:28:08, Brad Beckmann wrote: configs/example/ruby_mem_test.py, line 97 http://reviews.m5sim.org/r/611/diff/6/?file=11542#file11542line97 It seems that the following three parameters should not be hardcoded, but instead should be set using command line options. Hardcoding the atomic parameter to false still makes sense, since Ruby can handle atomic requests. Also we should update the comment above. I did not add that line. I am not even aware what the purpose of that line is. I'll dig into what the implication of setting issue_dmas to false is. I will update the comment. On 2011-04-13 10:28:08, Brad Beckmann wrote: src/cpu/testers/memtest/memtest.cc, line 401 http://reviews.m5sim.org/r/611/diff/6/?file=11545#file11545line401 Remove commented out line Done! On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141 Why are you adding this function? SLICC already generates a similar function: getPermission(). Overall, I hope/think we can add functional access support without requiring any more changes to the protocol specific .sm files beyond the changeset: 8086:bf0335d98250 that I checked in a couple months ago. How would you use the function that is generated by SLICC inside the sm file? I am concerned about the visibility of the function. On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/ruby/system/CacheMemory.cc, line 270 http://reviews.m5sim.org/r/611/diff/6/?file=11563#file11563line270 Why are you commenting this line out? If you think it is no longer needed, just remove it. If we remove it, can we guarentee that the permission is initialized to some value? For instance, do we know whether the entry constructor will allows initialize the value? I expect the state to decide what the permission should be. On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/ruby/system/System.hh, line 132 http://reviews.m5sim.org/r/611/diff/6/?file=11573#file11573line132 Why are these functions static? I'm concerned that declaring these static will unecessarily restrict using Ruby in multiple system simulation. Also from my understanding of the code, there is no need to make them static. Perhaps I'm missing something. My bad! I think I did that under the impression that static variables can only be referenced in static functions. On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/ruby/system/RubyPort.cc, line 302 http://reviews.m5sim.org/r/611/diff/6/?file=11568#file11568line302 Overall, I really like the comments you added in this file. They really help clarify what is going on here. Just one minor correction: change Any copy to Any valid copy Done! On 2011-04-13 10:28:08, Brad Beckmann wrote: src/mem/ruby/system/DirectoryMemory.cc, line 246 http://reviews.m5sim.org/r/611/diff/6/?file=11565#file11565line246 Please align this statement. I am removing this line. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-12 16:35:34, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-12 16:35:34) 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/example/ruby_mem_test.py cb1e137ac35e configs/ruby/MESI_CMP_directory.py cb1e137ac35e configs/ruby/Ruby.py cb1e137ac35e src/cpu/testers/memtest/memtest.cc cb1e137ac35e src/mem/packet.hh cb1e137ac35e src/mem/packet.cc cb1e137ac35e src/mem/protocol/MESI_CMP_directory-L1cache.sm cb1e137ac35e src/mem/protocol/MESI_CMP_directory-L2cache.sm cb1e137ac35e src/mem/protocol/MESI_CMP_directory-dir.sm cb1e137ac35e src/mem/protocol/RubySlicc_Types.sm cb1e137ac35e src/mem/ruby/network/Network.cc cb1e137ac35e src/mem/ruby/network/Network.py cb1e137ac35e src/mem/ruby/profiler/Profiler.cc cb1e137ac35e src/mem/ruby/profiler/Profiler.py cb1e137ac35e src/mem/ruby/recorder/Tracer.cc cb1e137ac35e src/mem/ruby/recorder/Tracer.py cb1e137ac35e src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py cb1e137ac35e src/mem/ruby/system/CacheMemory.hh cb1e137ac35e src/mem/ruby/system/CacheMemory.cc cb1e137ac35e src/mem/ruby
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-04-13 11:17:53.272247) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs (updated) - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 8b5f900233ee src/mem/ruby/system/CacheMemory.hh 8b5f900233ee src/mem/ruby/system/CacheMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee src/mem/ruby/system/RubyPort.hh 8b5f900233ee src/mem/ruby/system/RubyPort.cc 8b5f900233ee src/mem/ruby/system/RubySystem.py 8b5f900233ee src/mem/ruby/system/SConscript 8b5f900233ee src/mem/ruby/system/Sequencer.cc 8b5f900233ee src/mem/ruby/system/Sequencer.py 8b5f900233ee src/mem/ruby/system/System.hh 8b5f900233ee src/mem/ruby/system/System.cc 8b5f900233ee src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] AccessPermission in AbstractEntry
On Mon, 11 Apr 2011, Beckmann, Brad wrote: Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. I will try to make this change later today. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad Is it not possible that we have a protocol in which different directory controllers may behave differently? -- Nilay -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Sunday, April 10, 2011 2:12 AM To: m5-dev@m5sim.org Subject: [m5-dev] AccessPermission in AbstractEntry Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] AccessPermission in AbstractEntry
Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Testing Functional Access
Brad, functional accesses work for the case when the only functional
accesses are allowed in the system. Currently I am working when the ratio
is 1:1 for functional and timing accesses.
I am facing some problem with the timing access right now, which should
work perfectly fine. Actually the value returned for a read packet is
coming out to be incorrect. I tracked the request, the response was
correct, but it seems that the packet was not updated properly. I
noticed that around line 530 in Sequencer.cc, the following code has been
added. Do you think we need such code for memtester as well? Should we not
be updating the subBlock when memtester is used?
// If using the RubyTester, update the RubyTester sender state's
// subBlock with the recieved data. The tester will later access
// this state.
// Note: RubyPort will access it's sender state before the
// RubyTester.
if (m_usingRubyTester) {
RubyPort::SenderState *requestSenderState =
safe_castRubyPort::SenderState*(ruby_request.pkt-senderState);
RubyTester::SenderState* testerSenderState =
(RubyTester::SenderState*)(requestSenderState-saved);
testerSenderState-subBlock-mergeFrom(data);
}
Thanks
Nilay
On Tue, 1 Mar 2011, Beckmann, Brad wrote:
I forgot that the memtester includes functional accesses. That is a
good suggestion, especially when it comes to testing the situations
where Ruby can't satisfy the functional access due to contention with
timing accesses.
The memtester does run with Ruby (it actually runs every night in the
regression tester), however the percentage of functional accesses is
currently set to zero. See configs/example/ruby_mem_test.py. You'll
obviously want to change that and include code within
src/cpu/testers/memtest/* to handle failed functional accesses. If you
don't want to initially deal with the failure situations, you can set
the functional access percentage to 100% and that should always work.
Brad
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Testing Functional Access
Brad, I figured out the error, so no need to respond to my previous mail.
--
Nilay
On Sat, 9 Apr 2011, Nilay Vaish wrote:
Brad, functional accesses work for the case when the only functional accesses
are allowed in the system. Currently I am working when the ratio is 1:1 for
functional and timing accesses.
I am facing some problem with the timing access right now, which should work
perfectly fine. Actually the value returned for a read packet is coming out
to be incorrect. I tracked the request, the response was correct, but it
seems that the packet was not updated properly. I noticed that around line
530 in Sequencer.cc, the following code has been added. Do you think we need
such code for memtester as well? Should we not be updating the subBlock when
memtester is used?
// If using the RubyTester, update the RubyTester sender state's
// subBlock with the recieved data. The tester will later access
// this state.
// Note: RubyPort will access it's sender state before the
// RubyTester.
if (m_usingRubyTester) {
RubyPort::SenderState *requestSenderState =
safe_castRubyPort::SenderState*(ruby_request.pkt-senderState);
RubyTester::SenderState* testerSenderState =
(RubyTester::SenderState*)(requestSenderState-saved);
testerSenderState-subBlock-mergeFrom(data);
}
Thanks
Nilay
On Tue, 1 Mar 2011, Beckmann, Brad wrote:
I forgot that the memtester includes functional accesses. That is a good
suggestion, especially when it comes to testing the situations where Ruby
can't satisfy the functional access due to contention with timing accesses.
The memtester does run with Ruby (it actually runs every night in the
regression tester), however the percentage of functional accesses is
currently set to zero. See configs/example/ruby_mem_test.py. You'll
obviously want to change that and include code within
src/cpu/testers/memtest/* to handle failed functional accesses. If you
don't want to initially deal with the failure situations, you can set the
functional access percentage to 100% and that should always work.
Brad
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
On Thu, 7 Apr 2011, Gabriel Michael Black wrote: When you say this is portable, what do you mean? Portable between compilers? We usually use gcc, but we have at least partial support for other compilers. I think this is necessary on some platforms. Gabe I would still root for using popcount() builtin available with GCC. -- Nilay Between different versions of gcc. Do we actually test whether the code compiles using other compilers? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
The problem is that LONG_BITS is 31, ie std::numeric_limitslong::digits
returns 31 and not 32 which is what the writer expected.
--
Nilay
From: koreylsew...@gmail.com [mailto:koreylsew...@gmail.com] On Behalf Of
Korey Sewell
Sent: Tuesday, April 05, 2011 7:14 AM
To: Beckmann, Brad
Subject: Re: [m5-dev] Running Ruby w/32 Cores
Hi again Brad, I looked this over again and although my 32-bit patch
fixes things, now that I look at it again, I'm not convinced that I
actually fixed the symptom of the bug but rather the cause of the bug.
Do you happen to know what are the problems with the 32-bit Set counts?
Sorry for prolonging the issue, but I thought I had put this to bed but
maybe not. Finally, it may not matter that this works on 32-bit machines
but it'd be nice if it did. (Let me know if I should move this convo to
the m5-dev list)
I end up checking the last bit in the count function manually (the code
as follows): int Set::count() const {
int counter = 0;
long mask;
for (int i = 0; i m_nArrayLen; i++) {
mask = (long)0x01;
for (int j = 0; j LONG_BITS; j++) {
// FIXME - significant performance loss when array
// population LONG_BITS
if ((m_p_nArray[i] mask) != 0) {
counter++;
}
mask = mask 1;
}
#ifndef _LP64
long msb_mask = 0x8000;
if ((m_p_nArray[i] msb_mask) != 0) {
counter++;
}
#endif
}
return counter;
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
On Thu, 7 Apr 2011, Gabriel Michael Black wrote: Quoting Nilay Vaish ni...@cs.wisc.edu: On Thu, 7 Apr 2011, Gabriel Michael Black wrote: When you say this is portable, what do you mean? Portable between compilers? We usually use gcc, but we have at least partial support for other compilers. I think this is necessary on some platforms. Gabe I would still root for using popcount() builtin available with GCC. -- Nilay Between different versions of gcc. Do we actually test whether the code compiles using other compilers? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev I don't know if we actively test it, but it worked at one time. Ali did some work on that, I think to get it to build with sun's compiler back when he was doing the SPARC full system support. It would be a good idea not to bake in any dependence on gcc. Gabe I agree with you. If we can avoid dependence on a compiler, we certainly should. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby: dbg: use system ticks instead of cycles
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/635/#review1102 --- src/mem/ruby/network/simple/PerfectSwitch.cc http://reviews.m5sim.org/r/635/#comment1467 If DPRINTF() prints the time, is this piece of code required? src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/635/#comment1468 Again, do we need curTick() here? src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/635/#comment1469 Same comment as before. - Nilay On 2011-04-05 11:19:26, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/635/ --- (Updated 2011-04-05 11:19:26) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: dbg: use system ticks instead of cycles It's easier to debug simulations (find the exact point to rerun a trace) when the output is in the system ticks instead of the Ruby cycle time Diffs - src/mem/ruby/buffers/MessageBuffer.cc 54a65799e4c1 src/mem/ruby/network/simple/PerfectSwitch.cc 54a65799e4c1 src/mem/ruby/system/Sequencer.cc 54a65799e4c1 src/mem/slicc/symbols/StateMachine.py 54a65799e4c1 src/mem/slicc/symbols/Type.py 54a65799e4c1 Diff: http://reviews.m5sim.org/r/635/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
On Wed, 6 Apr 2011, Korey Sewell wrote:
A few comments:
(1) Using uint64_t seems like a quick, interim solution. But I still
haven't grasped why we have the 31st bit problem, but we don't have
the 63rd bit problem as well?
I think if you use unsigned long, in place of long, the code would work on
32-bit machines. I am uncertain why the current code works on 64-bit
machine. I think long means 32-bit, irrespective of memory address length.
(2) Adding the stl::bitset seems like a good idea (does the Flags in
M5 use that?) but it wont be a straightforward switch because the Set
class supports arbitrary size sets. If it was implemented it would
take a little bit of effort but not too much.
(3) I didnt say this earlier, but it does look like this code could
use some optimization. From the gprof I ran on 2-8 cores, this
Set::count() function is the 2nd or 3rd highest producer of time for
the Ruby Fft runs (although still a very small overall % in system
time). Looks like simple optimizations like only looping for the set
size in the count() function should be helpful, instead of always
looping for the complete length of long datatype:
for (int j = 0; j LONG_BITS; j++) {
if ((m_p_nArray[i] mask) != 0) {
counter++;
}
mask = mask 1;
}
That as well as generating a mask, shifting and comparing each bit
doesn't seem necessary given we can potentially use a bitset or a
constant-time struct to loop over and check set inclusion.
I would still root for using popcount() builtin available with GCC.
--
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
On 2011-03-31 22:08:21, Brad Beckmann wrote: 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. Nilay Vaish wrote: Brad, I would make the changes you have listed below. I also need to add code for directory memory accesses. Can you elaborate on the next step you mentioned? We are yet not dealing with the devices, I believe. Nilay Vaish wrote: One more question for you. Do we need functional access support for the PioPort as well? We do not have it currently. Brad Beckmann wrote: Yes, eventually if we want Ruby to supply data in FS mode, RubyPort will need to support functional access from the PioPort to Ruby memory. It is up to you whether you want to implement that support now, or first make sure functional accesses are working SE mode. If you want to make sure SE mode functional accesses work, first modify the ruby mem tester to issue functional access (right now that is hardcoded off). Also you should try a few binaries under SE mode, like hello world. Brad, I'll test the current implementation first and then work on functional accesses from the PioPort. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- On 2011-04-02 11:42:47, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-02 11:42:47) 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 aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 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 support for functional accesses
On 2011-04-03 13:45:28, Brad Beckmann wrote: src/mem/ruby/system/DirectoryMemory.py, line 2 http://reviews.m5sim.org/r/611/diff/4/?file=11465#file11465line2 Why are you deleting this file and where are you moving the current functionality? My bad! I had forgotten to add AbstractMemory.py file. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1090 --- On 2011-04-02 11:42:47, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-02 11:42:47) 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 aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 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 support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-04 06:22:20.346203) 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 aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 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] Ruby Optimization Opportunity?
On Fri, 1 Apr 2011, Korey Sewell wrote: That's a good point. I'll coordinate with Nilay offline to get him the right image. Nilay, from your previous optimizations trials, where did you see most of the simulation time being sent at? On Fri, Apr 1, 2011 at 4:48 PM, Ali Saidi sa...@umich.edu wrote: None of those benchmarks probably push the memory system with multiple cores like fft. Why don't you give Nilay your fft benchmark? Ali Korey, I normally only run Ruby random tester to profile which parts of Ruby take most of the time. My observation was that wakeup() function for the L1 cache controller takes most of the time (about 10%). It would be good if you can provide me with the benchmark, I will investigate where the time is being spent and hopefully, we would be able to speed up the simulation. Thanks 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
On 2011-03-31 22:08:21, Brad Beckmann wrote: 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. Nilay Vaish wrote: Brad, I would make the changes you have listed below. I also need to add code for directory memory accesses. Can you elaborate on the next step you mentioned? We are yet not dealing with the devices, I believe. One more question for you. Do we need functional access support for the PioPort as well? We do not have it currently. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- On 2011-04-02 11:42:47, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-02 11:42:47) 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 aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 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 support for functional accesses
On 2011-04-01 09:30:54, Brad Beckmann wrote: Hi Nilay, Comments below. I might be missing something, but the changes to DirectoryMemory seem straightforward. No, you are not missing anything. It is just that I had not implemented it up till now. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1085 --- 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
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
On 2011-03-31 22:08:21, Brad Beckmann wrote: src/mem/ruby/system/RubyPort.cc, line 417 http://reviews.m5sim.org/r/611/diff/3/?file=11443#file11443line417 Are functional packets put on the stack or the heap? I seem to remember the former, but I could be wrong. In a couple of places in src/mem/port.cc, the packet is on the stack. But in src/cpu/testers/memtest/memtest.cc, the packet is on the heap. As per the documentation, the packet is owned by the requestor. So, the requestor will have to free the packet. I will remove this code. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- 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
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-04-02 11:42:47.195024) 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 aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 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 support for functional accesses
On 2011-03-31 22:08:21, Brad Beckmann wrote: 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. Brad, I would make the changes you have listed below. I also need to add code for directory memory accesses. Can you elaborate on the next step you mentioned? We are yet not dealing with the devices, I believe. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- 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
[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: 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] 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
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: 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: 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: 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: 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-30 16:19:26.551926) 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 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 support for functional accesses
On Tue, 29 Mar 2011, Nilay Vaish wrote: Brad, I have posted on the review board my current implementation for supporting functional accesses in Ruby. This is untested and is mainly meant for furthering the discussions. I have some questions for you -- 1. How do we inform the other end of RubyPort's M5 Port about whether or not functional access was successful? 2. What's the role of directory memory in functional accesses? 3. If none of the caches have the block pertaining to the address of the access, then read accesses should be satisfied from the physical memory. Write accesses should always go to physical memory as well. How can physical memory be accessed from RubyPort? -- Nilay Brad, I have made some changes to the patch. I have updated it on the review board. I have added a call to sendFunctional() so as to send the response. I have also added call to sendFunctional() on the physical memory port of ruby port, so that the physical memory would also get updated. You had mentioned that we would unhook M5 memory and use Ruby to supply the data. How do we do this? And the second question from the previous mail still remains unanswered. Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby Optimization Opportunity?
Korey, I do not have the FftBase32 benchmark. Is it possible for you to run the simulation with one of the following benchmarks -- IScsiInitiator, IScsiTarget, MutexTest, NetperfMaerts, NetperfStream, NetperfStreamNT, NetperfStreamUdp, NetperfUdpLocal, Nfs, NfsTcp, Nhfsstone, Ping, PovrayAutumn, PovrayBench, SurgeSpecweb, SurgeStandard, ValAccDelay, ValAccDelay2, ValCtxLat, ValMemLat, ValMemLat2MB, ValMemLat8MB, ValStream, ValStreamCopy, ValStreamScale, ValSysLat, ValTlbLat, Validation, bnAn Which of these do you think would closely resemble FFT? Nilay On Wed, 30 Mar 2011, Korey Sewell wrote: Hi all, I had noticed that Ruby was running a little slower than the old M5 memory system and decided to run gprof on it to see if there was anything obvious holding things up. For 2, 4, and 8 core ALPHA_FS_MOESI_CMP_directory, SimpleCPU runs for the Fft benchmark, it seems that the MemoryControl::executeCycle conributes to nearly 30% of the runtime. Looking at the comments for that code, I see this: // executeCycle: This function is called once per memory clock cycle I'm not familiar with this Memory Controller code but it would seem that some type of optimization not requiring this to be run every memory cycle would speed things up a good bit. So if someone has the time or the need to do some Ruby optimization work (i know Nilay had did some previously), then I think this will be a good place to start... I post some of the gprof output below: = 2 core = time (%) name 29.17 MemoryControl::executeCycle() 4.19RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.52PerfectSwitch::wakeup() 3.47Set::Set(Set const) 3.46RubyEventQueueNode::process() 4 core = time (%) name 27.49MemoryControl::executeCycle() 4.01RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.66PerfectSwitch::wakeup() 3.59 Set::Set(Set const) 3.50RubyEventQueueNode::process() 8 core = time (%) name 26.09MemoryControl::executeCycle() 4.12 Set::Set(Set const) 3.91 PerfectSwitch::wakeup() 3.88 RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.41 RubyEventQueueNode::process() -- - 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
[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/ --- 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 6ae58f06a41c configs/ruby/Ruby.py 6ae58f06a41c src/mem/ruby/network/Network.cc 6ae58f06a41c src/mem/ruby/network/Network.py 6ae58f06a41c src/mem/ruby/profiler/Profiler.cc 6ae58f06a41c src/mem/ruby/profiler/Profiler.py 6ae58f06a41c src/mem/ruby/recorder/Tracer.cc 6ae58f06a41c src/mem/ruby/recorder/Tracer.py 6ae58f06a41c src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py 6ae58f06a41c src/mem/ruby/system/CacheMemory.hh 6ae58f06a41c src/mem/ruby/system/CacheMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.hh 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.py 6ae58f06a41c src/mem/ruby/system/RubyPort.hh 6ae58f06a41c src/mem/ruby/system/RubyPort.cc 6ae58f06a41c src/mem/ruby/system/RubySystem.py 6ae58f06a41c src/mem/ruby/system/SConscript 6ae58f06a41c src/mem/ruby/system/Sequencer.py 6ae58f06a41c src/mem/ruby/system/System.hh 6ae58f06a41c src/mem/ruby/system/System.cc 6ae58f06a41c 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 support for functional accesses
Brad, I have posted on the review board my current implementation for supporting functional accesses in Ruby. This is untested and is mainly meant for furthering the discussions. I have some questions for you -- 1. How do we inform the other end of RubyPort's M5 Port about whether or not functional access was successful? 2. What's the role of directory memory in functional accesses? 3. If none of the caches have the block pertaining to the address of the access, then read accesses should be satisfied from the physical memory. Write accesses should always go to physical memory as well. How can physical memory be accessed from RubyPort? -- Nilay On Tue, 29 Mar 2011, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- 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. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Config: Import math in MI_example.py
changeset 1333bd6cc2eb in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=1333bd6cc2eb description: Config: Import math in MI_example.py diffstat: configs/ruby/MI_example.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r 832ae3727c2b -r 1333bd6cc2eb configs/ruby/MI_example.py --- a/configs/ruby/MI_example.pySat Mar 26 22:24:36 2011 -0700 +++ b/configs/ruby/MI_example.pyMon Mar 28 10:49:36 2011 -0500 @@ -27,6 +27,7 @@ # # Authors: Brad Beckmann +import math import m5 from m5.objects import * from m5.defines import buildEnv ___ 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 pushed in patch that imports math in MI_example.py -- Nilay On Mon, 28 Mar 2011, Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby FAILED! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby random tester failing with MESI_CMP_directory?
I will try to bisect this. -- Nilay On Wed, 23 Mar 2011, Arkaprava Basu wrote: Hi Lisa and Nilay, Thanks for the response. Following is the tip of my repo changeset: 8174:e21f6e70169e tag: tip user:Nilay Vaishni...@cs.wisc.edu date:Tue Mar 22 06:41:54 2011 -0500 summary: Ruby: Remove CacheMsg class from SLICC So this is after Nilay's patch for CacheMsg. And yes it did not tun for 10-15 mins, died immediately. The architecture should not matter for random_tester. I am not sure then why its breaking. Seems like something broken. Thanks Arka ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby random tester failing with MESI_CMP_directory?
It is working fine for me. ./build/X86_SE_MESI_CMP_directory/m5.fast ./configs/example/ruby_random_test.py -n 4 -l 1 M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Mar 23 2011 15:53:38 M5 started Mar 23 2011 15:53:52 M5 executing on mumble-09.cs.wisc.edu command line: ./build/X86_SE_MESI_CMP_directory/m5.fast ./configs/example/ruby_random_test.py -n 4 -l 1 Global frequency set at 10 ticks per second info: Entering event queue @ 0. Starting simulation... hack: be nice to actually delete the event here Exiting @ tick 14536941 because Ruby Tester completed On Wed, 23 Mar 2011, Nilay Vaish wrote: I will try to bisect this. -- Nilay On Wed, 23 Mar 2011, Arkaprava Basu wrote: Hi Lisa and Nilay, Thanks for the response. Following is the tip of my repo changeset: 8174:e21f6e70169e tag: tip user:Nilay Vaishni...@cs.wisc.edu date:Tue Mar 22 06:41:54 2011 -0500 summary: Ruby: Remove CacheMsg class from SLICC So this is after Nilay's patch for CacheMsg. And yes it did not tun for 10-15 mins, died immediately. The architecture should not matter for random_tester. I am not sure then why its breaking. Seems like something broken. Thanks Arka ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Remove CacheMsg class from SLICC
changeset e21f6e70169e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e21f6e70169e
description:
Ruby: Remove CacheMsg class from SLICC
The goal of the patch is to do away with the CacheMsg class currently
in use
in coherence protocols. In place of CacheMsg, the RubyRequest class
will used.
This class is already present in slicc_interface/RubyRequest.hh. In
fact,
objects of class CacheMsg are generated by copying values from a
RubyRequest
object.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 12 +-
src/mem/protocol/MI_example-cache.sm |6 +-
src/mem/protocol/MOESI_CMP_directory-L1cache.sm | 10 +-
src/mem/protocol/MOESI_CMP_token-L1cache.sm | 12 +-
src/mem/protocol/MOESI_hammer-cache.sm |8 +-
src/mem/protocol/Network_test-cache.sm |4 +-
src/mem/protocol/RubySlicc_Exports.sm| 11 -
src/mem/protocol/RubySlicc_Profiler.sm |4 +-
src/mem/protocol/RubySlicc_Types.sm | 12 +-
src/mem/ruby/profiler/AddressProfiler.cc |2 +-
src/mem/ruby/profiler/AddressProfiler.hh |2 +-
src/mem/ruby/profiler/Profiler.cc|4 +-
src/mem/ruby/profiler/Profiler.hh|4 +-
src/mem/ruby/recorder/TraceRecord.cc |2 +-
src/mem/ruby/slicc_interface/RubyRequest.cc | 41 +--
src/mem/ruby/slicc_interface/RubyRequest.hh | 104 +++-
src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh |4 +-
src/mem/ruby/slicc_interface/RubySlicc_Util.hh |2 -
src/mem/ruby/system/CacheMemory.cc |2 +-
src/mem/ruby/system/CacheMemory.hh |4 +-
src/mem/ruby/system/DMASequencer.cc |6 +-
src/mem/ruby/system/RubyPort.cc |2 +-
src/mem/ruby/system/Sequencer.cc | 116 +-
23 files changed, 208 insertions(+), 166 deletions(-)
diffs (truncated from 893 to 300 lines):
diff -r 2c47dc111abd -r e21f6e70169e
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smMon Mar 21 22:51:59
2011 -0400
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smTue Mar 22 06:41:54
2011 -0500
@@ -267,9 +267,9 @@
}
// Mandatory Queue betweens Node's CPU and it's L1 caches
- in_port(mandatoryQueue_in, CacheMsg, mandatoryQueue, desc=...) {
+ in_port(mandatoryQueue_in, RubyRequest, mandatoryQueue, desc=...) {
if (mandatoryQueue_in.isReady()) {
- peek(mandatoryQueue_in, CacheMsg, block_on=LineAddress) {
+ peek(mandatoryQueue_in, RubyRequest, block_on=LineAddress) {
// Check for data access to blocks in I-cache and ifetchs to blocks in
D-cache
@@ -338,7 +338,7 @@
// ACTIONS
action(a_issueGETS, a, desc=Issue GETS) {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
enqueue(requestIntraChipL1Network_out, RequestMsg,
latency=l1_request_latency) {
out_msg.Address := address;
out_msg.Type := CoherenceRequestType:GETS;
@@ -355,7 +355,7 @@
}
action(ai_issueGETINSTR, ai, desc=Issue GETINSTR) {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
enqueue(requestIntraChipL1Network_out, RequestMsg,
latency=l1_request_latency) {
out_msg.Address := address;
out_msg.Type := CoherenceRequestType:GET_INSTR;
@@ -373,7 +373,7 @@
action(b_issueGETX, b, desc=Issue GETX) {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
enqueue(requestIntraChipL1Network_out, RequestMsg,
latency=l1_request_latency) {
out_msg.Address := address;
out_msg.Type := CoherenceRequestType:GETX;
@@ -391,7 +391,7 @@
}
action(c_issueUPGRADE, c, desc=Issue GETX) {
-peek(mandatoryQueue_in, CacheMsg) {
+peek(mandatoryQueue_in, RubyRequest) {
enqueue(requestIntraChipL1Network_out, RequestMsg, latency=
l1_request_latency) {
out_msg.Address := address;
out_msg.Type := CoherenceRequestType:UPGRADE;
diff -r 2c47dc111abd -r e21f6e70169e src/mem/protocol/MI_example-cache.sm
--- a/src/mem/protocol/MI_example-cache.sm Mon Mar 21 22:51:59 2011 -0400
+++ b/src/mem/protocol/MI_example-cache.sm Tue Mar 22 06:41:54 2011 -0500
@@ -181,9 +181,9 @@
}
// Mandatory Queue
- in_port(mandatoryQueue_in, CacheMsg, mandatoryQueue, desc=...) {
+ in_port(mandatoryQueue_in, RubyRequest, mandatoryQueue, desc=...) {
if (mandatoryQueue_in.isReady()) {
- peek(mandatoryQueue_in, CacheMsg, block_on=LineAddress) {
+ peek(mandatoryQueue_in, RubyRequest,
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
On Tue, 22 Mar 2011, Gabriel Michael Black wrote: The two issues below are copied from ARM_FS, but other targets had the same problems. These errors are making the build fail. build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::completeRequest(Packet*)': build/ARM_FS/cpu/testers/networktest/networktest.cc:160: warning: unused variable 'req' build/ARM_FS/cpu/testers/networktest/networktest.cc: In member function 'void NetworkTest::tick()': build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call of overloaded 'pow(int, int)' is ambiguous These warnings should probably be cleaned up too, although I don't know how long they've been there or how hard that would be. The warnings related to networktest.cc got added yesterday. build/ARM_FS/mem/ruby/system/Sequencer.cc: In member function 'void Sequencer::issueRequest(const RubyRequest)': build/ARM_FS/mem/ruby/system/Sequencer.cc:616: warning: 'ctype' may be used uninitialized in this function build/ARM_FS/mem/ruby/system/Sequencer.cc:653: warning: 'amtype' may be used uninitialized in this function These I think have been around for quite a while. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: SLICC: Remove WakeUp* import calls from ast/__i...
changeset c1c6f36e118e in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c1c6f36e118e description: SLICC: Remove WakeUp* import calls from ast/__init__.py I had recently committed a patch that removed the WakeUp*.py files from the slicc/ast directory. I had forgotten to remove the import calls for these files from slicc/ast/__init__.py. This resulted in error while running regressions on zizzer. This patch does the needful. diffstat: src/mem/slicc/ast/__init__.py | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diffs (9 lines): diff -r 89cd8302abd3 -r c1c6f36e118e src/mem/slicc/ast/__init__.py --- a/src/mem/slicc/ast/__init__.py Sat Mar 19 21:13:04 2011 -0700 +++ b/src/mem/slicc/ast/__init__.py Sun Mar 20 09:23:27 2011 -0500 @@ -74,5 +74,3 @@ from slicc.ast.TypeFieldMethodAST import * from slicc.ast.TypeFieldStateAST import * from slicc.ast.VarExprAST import * -from slicc.ast.WakeUpAllDependentsStatementAST import * -from slicc.ast.WakeUpDependentsStatementAST import * ___ 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 --scratch all
I had committed an error in one of the my recent patches. I have committed a patch that should fix this error. -- Nilay On Sun, 20 Mar 2011, Cron Daemon wrote: See /z/m5/regression/regress-2011-03-20-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] Review Request: Ruby: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-03-20 10:53:10.248023) Review request for Default. Summary (updated) --- Ruby: Remove CacheMsg class from SLICC The goal of the patch is to do away with the CacheMsg class currently in use in coherence protocols. In place of CacheMsg, the RubyRequest class will used. This class is already present in slicc_interface/RubyRequest.hh. In fact, objects of class CacheMsg are generated by copying values from a RubyRequest object. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm c1c6f36e118e src/mem/protocol/MI_example-cache.sm c1c6f36e118e src/mem/protocol/MOESI_CMP_directory-L1cache.sm c1c6f36e118e src/mem/protocol/MOESI_CMP_token-L1cache.sm c1c6f36e118e src/mem/protocol/MOESI_hammer-cache.sm c1c6f36e118e src/mem/protocol/RubySlicc_Exports.sm c1c6f36e118e src/mem/protocol/RubySlicc_Profiler.sm c1c6f36e118e src/mem/protocol/RubySlicc_Types.sm c1c6f36e118e src/mem/ruby/profiler/AddressProfiler.hh c1c6f36e118e src/mem/ruby/profiler/AddressProfiler.cc c1c6f36e118e src/mem/ruby/profiler/Profiler.hh c1c6f36e118e src/mem/ruby/profiler/Profiler.cc c1c6f36e118e src/mem/ruby/recorder/TraceRecord.cc c1c6f36e118e src/mem/ruby/slicc_interface/RubyRequest.hh c1c6f36e118e src/mem/ruby/slicc_interface/RubyRequest.cc c1c6f36e118e src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh c1c6f36e118e src/mem/ruby/slicc_interface/RubySlicc_Util.hh c1c6f36e118e src/mem/ruby/system/CacheMemory.hh c1c6f36e118e src/mem/ruby/system/CacheMemory.cc c1c6f36e118e src/mem/ruby/system/DMASequencer.cc c1c6f36e118e src/mem/ruby/system/RubyPort.cc c1c6f36e118e src/mem/ruby/system/Sequencer.cc c1c6f36e118e Diff: http://reviews.m5sim.org/r/327/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
On Sat, 19 Mar 2011, Nilay Vaish wrote: On Fri, 18 Mar 2011, Lisa Hsu wrote: What's going on with this patch? I don't believe it's been committed but it seems like it should. I've also got some patches waiting behind this because they used to touch CacheMsg and I don't want to mess Nilay up, so I've been waiting to serialize behind this. Lisa Lisa, the original patch was pretty long and after some of the changes that Brad submitted, almost the whole of the patch required rework. I have already committed some parts of the original patch. I have posted two more patches on the review board that cover some more portion of the patch. You can ignore the original patch. Assume that I will not post more patches that touch CacheMsg or related structures apart from the two that I posted 5 minutes ago. -- Nilay Lisa, I have updated the patch. If you want, you can commit your patches before I commit this. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ruby: Convert AccessModeType to RubyAccessMode
changeset b043c0efa024 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=b043c0efa024
description:
Ruby: Convert AccessModeType to RubyAccessMode
This patch converts AccessModeType to RubyAccessMode so that both the
protocol dependent and independent code uses the same access mode.
diffstat:
src/cpu/testers/rubytest/Check.cc | 2 +-
src/cpu/testers/rubytest/Check.hh | 4 ++--
src/mem/protocol/MESI_CMP_directory-msg.sm | 2 +-
src/mem/protocol/MOESI_CMP_directory-msg.sm| 2 +-
src/mem/protocol/MOESI_CMP_token-L1cache.sm| 2 +-
src/mem/protocol/MOESI_CMP_token-dir.sm| 8
src/mem/protocol/MOESI_CMP_token-msg.sm| 4 ++--
src/mem/protocol/RubySlicc_Exports.sm | 13 +++--
src/mem/protocol/RubySlicc_Types.sm| 2 +-
src/mem/ruby/profiler/AccessTraceForAddress.cc | 4 ++--
src/mem/ruby/profiler/AccessTraceForAddress.hh | 4 ++--
src/mem/ruby/profiler/AddressProfiler.cc | 6 +++---
src/mem/ruby/profiler/AddressProfiler.hh | 2 +-
src/mem/ruby/profiler/CacheProfiler.cc | 12 ++--
src/mem/ruby/profiler/CacheProfiler.hh | 10 +-
src/mem/ruby/profiler/Profiler.hh | 2 +-
src/mem/ruby/slicc_interface/RubyRequest.hh| 8 +---
src/mem/ruby/system/CacheMemory.cc | 2 +-
src/mem/ruby/system/CacheMemory.hh | 2 +-
src/mem/ruby/system/Sequencer.cc | 10 +-
src/mem/ruby/system/Sequencer.hh | 4 ++--
21 files changed, 50 insertions(+), 55 deletions(-)
diffs (truncated from 471 to 300 lines):
diff -r 19a654839a04 -r b043c0efa024 src/cpu/testers/rubytest/Check.cc
--- a/src/cpu/testers/rubytest/Check.cc Sat Mar 19 14:17:48 2011 -0700
+++ b/src/cpu/testers/rubytest/Check.cc Sat Mar 19 18:34:37 2011 -0500
@@ -44,7 +44,7 @@
pickInitiatingNode();
changeAddress(address);
m_pc = pc;
-m_access_mode = AccessModeType(random() % AccessModeType_NUM);
+m_access_mode = RubyAccessMode(random() % RubyAccessMode_NUM);
m_store_count = 0;
}
diff -r 19a654839a04 -r b043c0efa024 src/cpu/testers/rubytest/Check.hh
--- a/src/cpu/testers/rubytest/Check.hh Sat Mar 19 14:17:48 2011 -0700
+++ b/src/cpu/testers/rubytest/Check.hh Sat Mar 19 18:34:37 2011 -0500
@@ -33,7 +33,7 @@
#include iostream
#include cpu/testers/rubytest/RubyTester.hh
-#include mem/protocol/AccessModeType.hh
+#include mem/protocol/RubyAccessMode.hh
#include mem/protocol/TesterStatus.hh
#include mem/ruby/common/Address.hh
#include mem/ruby/common/Global.hh
@@ -73,7 +73,7 @@
NodeID m_initiatingNode;
Address m_address;
Address m_pc;
-AccessModeType m_access_mode;
+RubyAccessMode m_access_mode;
int m_num_cpu_sequencers;
RubyTester* m_tester_ptr;
};
diff -r 19a654839a04 -r b043c0efa024 src/mem/protocol/MESI_CMP_directory-msg.sm
--- a/src/mem/protocol/MESI_CMP_directory-msg.smSat Mar 19 14:17:48
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-msg.smSat Mar 19 18:34:37
2011 -0500
@@ -62,7 +62,7 @@
structure(RequestMsg, desc=..., interface=NetworkMessage) {
Address Address, desc=Physical address for this request;
CoherenceRequestType Type,desc=Type of request (GetS, GetX, PutX, etc);
- AccessModeType AccessMode,desc=user/supervisor access type;
+ RubyAccessMode AccessMode,desc=user/supervisor access type;
MachineID Requestor ,desc=What component request;
NetDest Destination, desc=What components receive the request,
includes MachineType and num;
MessageSizeType MessageSize, desc=size category of the message;
diff -r 19a654839a04 -r b043c0efa024 src/mem/protocol/MOESI_CMP_directory-msg.sm
--- a/src/mem/protocol/MOESI_CMP_directory-msg.sm Sat Mar 19 14:17:48
2011 -0700
+++ b/src/mem/protocol/MOESI_CMP_directory-msg.sm Sat Mar 19 18:34:37
2011 -0500
@@ -84,7 +84,7 @@
DataBlock DataBlk, desc=data for the cache line (DMA WRITE
request);
int Acks,desc=How many acks to expect;
MessageSizeType MessageSize, desc=size category of the message;
- AccessModeType AccessMode,desc=user/supervisor access type;
+ RubyAccessMode AccessMode,desc=user/supervisor access type;
PrefetchBit Prefetch, desc=Is this a prefetch request;
}
diff -r 19a654839a04 -r b043c0efa024 src/mem/protocol/MOESI_CMP_token-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_token-L1cache.sm Sat Mar 19 14:17:48
2011 -0700
+++ b/src/mem/protocol/MOESI_CMP_token-L1cache.sm Sat Mar 19 18:34:37
2011 -0500
@@ -149,7 +149,7 @@
AccessType AccessType,desc=Type of request (used for
profiling);
Time IssueTime, desc=Time the request was issued;
-AccessModeType AccessMode,desc=user/supervisor access type;
+RubyAccessMode AccessMode,desc=user/supervisor
[m5-dev] changeset in m5: Ruby: Convert CacheRequestType to RubyRequestType
changeset 5955406f7ed0 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=5955406f7ed0
description:
Ruby: Convert CacheRequestType to RubyRequestType
This patch converts CacheRequestType to RubyRequestType so that both the
protocol dependent and independent code makes use of the same request
type.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 12 ++--
src/mem/protocol/MI_example-cache.sm| 10 +-
src/mem/protocol/MOESI_CMP_directory-L1cache.sm | 12 ++--
src/mem/protocol/MOESI_CMP_token-L1cache.sm | 24
src/mem/protocol/MOESI_hammer-cache.sm | 14 ++--
src/mem/protocol/RubySlicc_Exports.sm | 28 ++
src/mem/ruby/profiler/AccessTraceForAddress.cc | 8 +-
src/mem/ruby/profiler/AccessTraceForAddress.hh | 4 +-
src/mem/ruby/profiler/AddressProfiler.cc| 6 +-
src/mem/ruby/profiler/AddressProfiler.hh| 2 +-
src/mem/ruby/profiler/CacheProfiler.cc | 12 ++--
src/mem/ruby/profiler/CacheProfiler.hh | 4 +-
src/mem/ruby/profiler/Profiler.cc | 8 +-
src/mem/ruby/profiler/Profiler.hh | 4 +-
src/mem/ruby/recorder/CacheRecorder.hh | 2 +-
src/mem/ruby/recorder/Tracer.hh | 2 +-
src/mem/ruby/slicc_interface/RubyRequest.cc | 63 -
src/mem/ruby/slicc_interface/RubyRequest.hh | 18 +--
src/mem/ruby/slicc_interface/RubySlicc_Util.hh | 2 +-
src/mem/ruby/system/CacheMemory.cc | 16 +++---
src/mem/ruby/system/CacheMemory.hh | 6 +-
src/mem/ruby/system/DMASequencer.cc | 10 +---
src/mem/ruby/system/Sequencer.cc| 16 +++---
src/mem/ruby/system/Sequencer.hh| 4 +-
24 files changed, 103 insertions(+), 184 deletions(-)
diffs (truncated from 786 to 300 lines):
diff -r b043c0efa024 -r 5955406f7ed0
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smSat Mar 19 18:34:37
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smSat Mar 19 18:34:59
2011 -0500
@@ -183,15 +183,15 @@
}
}
- Event mandatory_request_type_to_event(CacheRequestType type) {
-if (type == CacheRequestType:LD) {
+ Event mandatory_request_type_to_event(RubyRequestType type) {
+if (type == RubyRequestType:LD) {
return Event:Load;
-} else if (type == CacheRequestType:IFETCH) {
+} else if (type == RubyRequestType:IFETCH) {
return Event:Ifetch;
-} else if ((type == CacheRequestType:ST) || (type ==
CacheRequestType:ATOMIC)) {
+} else if ((type == RubyRequestType:ST) || (type ==
RubyRequestType:ATOMIC)) {
return Event:Store;
} else {
- error(Invalid CacheRequestType);
+ error(Invalid RubyRequestType);
}
}
@@ -273,7 +273,7 @@
// Check for data access to blocks in I-cache and ifetchs to blocks in
D-cache
-if (in_msg.Type == CacheRequestType:IFETCH) {
+if (in_msg.Type == RubyRequestType:IFETCH) {
// ** INSTRUCTION ACCESS ***
Entry L1Icache_entry := getL1ICacheEntry(in_msg.LineAddress);
diff -r b043c0efa024 -r 5955406f7ed0 src/mem/protocol/MI_example-cache.sm
--- a/src/mem/protocol/MI_example-cache.sm Sat Mar 19 18:34:37 2011 -0500
+++ b/src/mem/protocol/MI_example-cache.sm Sat Mar 19 18:34:59 2011 -0500
@@ -84,15 +84,15 @@
}
// FUNCTIONS
- Event mandatory_request_type_to_event(CacheRequestType type) {
- if (type == CacheRequestType:LD) {
+ Event mandatory_request_type_to_event(RubyRequestType type) {
+ if (type == RubyRequestType:LD) {
return Event:Load;
-} else if (type == CacheRequestType:IFETCH) {
+} else if (type == RubyRequestType:IFETCH) {
return Event:Ifetch;
-} else if ((type == CacheRequestType:ST) || (type ==
CacheRequestType:ATOMIC)) {
+} else if ((type == RubyRequestType:ST) || (type ==
RubyRequestType:ATOMIC)) {
return Event:Store;
} else {
- error(Invalid CacheRequestType);
+ error(Invalid RubyRequestType);
}
}
diff -r b043c0efa024 -r 5955406f7ed0
src/mem/protocol/MOESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_directory-L1cache.sm Sat Mar 19 18:34:37
2011 -0500
+++ b/src/mem/protocol/MOESI_CMP_directory-L1cache.sm Sat Mar 19 18:34:59
2011 -0500
@@ -194,15 +194,15 @@
}
}
- Event mandatory_request_type_to_event(CacheRequestType type) {
-if (type == CacheRequestType:LD) {
+ Event mandatory_request_type_to_event(RubyRequestType type) {
+if (type == RubyRequestType:LD) {
return Event:Load;
-} else if (type == CacheRequestType:IFETCH) {
+} else if (type == RubyRequestType:IFETCH) {
return Event:Ifetch;
-} else if ((type == CacheRequestType:ST) || (type ==
CacheRequestType:ATOMIC)) {
+} else if ((type == RubyRequestType:ST) || (type ==
RubyRequestType:ATOMIC)) {
[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_all_dependents
changeset f3d1493787d4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f3d1493787d4
description:
SLICC: Remove the keyword wake_up_all_dependents
In order to add stall and wait facility for protocols, a keyword
wake_up_all_dependents was introduced. This patch removes the keyword,
instead this functionality is now implemented as function call.
diffstat:
src/mem/protocol/MOESI_CMP_token-L1cache.sm | 3 +-
src/mem/protocol/MOESI_hammer-cache.sm | 3 +-
src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py | 43
src/mem/slicc/parser.py | 5 --
src/mem/slicc/symbols/StateMachine.py| 40 +
5 files changed, 25 insertions(+), 69 deletions(-)
diffs (160 lines):
diff -r e641f702653a -r f3d1493787d4 src/mem/protocol/MOESI_CMP_token-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_token-L1cache.sm Fri Mar 18 11:47:15
2011 -0700
+++ b/src/mem/protocol/MOESI_CMP_token-L1cache.sm Fri Mar 18 14:12:01
2011 -0500
@@ -176,6 +176,7 @@
void unset_cache_entry();
void set_tbe(TBE b);
void unset_tbe();
+ void wakeUpAllBuffers();
TBETable L1_TBEs, template_hack=L1Cache_TBE;
@@ -1525,7 +1526,7 @@
}
action(ka_wakeUpAllDependents, ka, desc=wake-up all dependents) {
-wake_up_all_dependents();
+wakeUpAllBuffers();
}
//*
diff -r e641f702653a -r f3d1493787d4 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 11:47:15 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:01 2011 -0500
@@ -158,6 +158,7 @@
void unset_cache_entry();
void set_tbe(TBE b);
void unset_tbe();
+ void wakeUpAllBuffers();
Entry getCacheEntry(Address address), return_by_pointer=yes {
Entry L2cache_entry := static_cast(Entry, pointer,
L2cacheMemory.lookup(address));
@@ -1016,7 +1017,7 @@
}
action(ka_wakeUpAllDependents, ka, desc=wake-up all dependents) {
-wake_up_all_dependents();
+wakeUpAllBuffers();
}
//*
diff -r e641f702653a -r f3d1493787d4
src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py
--- a/src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py Fri Mar 18
11:47:15 2011 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +
@@ -1,43 +0,0 @@
-# Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# 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.
-
-from slicc.ast.StatementAST import StatementAST
-
-class WakeUpAllDependentsStatementAST(StatementAST):
-def __init__(self, slicc):
-super(StatementAST, self).__init__(slicc)
-
-def __repr__(self):
-return [WakeUpAllDependentsStatementAst: %r] % self.variable
-
-def generate(self, code, return_type):
-code('''
-if (m_waiting_buffers.size() 0) {
-wakeUpAllBuffers();
-}
-''')
diff -r e641f702653a -r f3d1493787d4 src/mem/slicc/parser.py
--- a/src/mem/slicc/parser.py Fri Mar 18 11:47:15 2011 -0700
+++ b/src/mem/slicc/parser.py Fri Mar 18 14:12:01 2011 -0500
@@ -160,7 +160,6 @@
'peek' : 'PEEK',
'stall_and_wait' : 'STALL_AND_WAIT',
'wake_up_dependents' : 'WAKE_UP_DEPENDENTS',
-'wake_up_all_dependents' : 'WAKE_UP_ALL_DEPENDENTS',
[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_dependents
changeset 099771c7725d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=099771c7725d
description:
SLICC: Remove the keyword wake_up_dependents
In order to add stall and wait facility for protocols, a keyword
wake_up_dependents was introduced. This patch removes the keyword,
instead this functionality is now implemented as function call.
diffstat:
src/mem/protocol/MOESI_CMP_token-L1cache.sm | 3 +-
src/mem/protocol/MOESI_hammer-cache.sm| 3 +-
src/mem/protocol/MOESI_hammer-dir.sm | 3 +-
src/mem/slicc/ast/WakeUpDependentsStatementAST.py | 46 ---
src/mem/slicc/parser.py | 5 --
src/mem/slicc/symbols/StateMachine.py | 24 ++-
6 files changed, 19 insertions(+), 65 deletions(-)
diffs (168 lines):
diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_CMP_token-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_token-L1cache.sm Fri Mar 18 14:12:01
2011 -0500
+++ b/src/mem/protocol/MOESI_CMP_token-L1cache.sm Fri Mar 18 14:12:03
2011 -0500
@@ -177,6 +177,7 @@
void set_tbe(TBE b);
void unset_tbe();
void wakeUpAllBuffers();
+ void wakeUpBuffers(Address a);
TBETable L1_TBEs, template_hack=L1Cache_TBE;
@@ -1522,7 +1523,7 @@
}
action(kd_wakeUpDependents, kd, desc=wake-up dependents) {
-wake_up_dependents(address);
+wakeUpBuffers(address);
}
action(ka_wakeUpAllDependents, ka, desc=wake-up all dependents) {
diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:01 2011 -0500
+++ b/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:03 2011 -0500
@@ -159,6 +159,7 @@
void set_tbe(TBE b);
void unset_tbe();
void wakeUpAllBuffers();
+ void wakeUpBuffers(Address a);
Entry getCacheEntry(Address address), return_by_pointer=yes {
Entry L2cache_entry := static_cast(Entry, pointer,
L2cacheMemory.lookup(address));
@@ -1013,7 +1014,7 @@
}
action(kd_wakeUpDependents, kd, desc=wake-up dependents) {
-wake_up_dependents(address);
+wakeUpBuffers(address);
}
action(ka_wakeUpAllDependents, ka, desc=wake-up all dependents) {
diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_hammer-dir.sm
--- a/src/mem/protocol/MOESI_hammer-dir.sm Fri Mar 18 14:12:01 2011 -0500
+++ b/src/mem/protocol/MOESI_hammer-dir.sm Fri Mar 18 14:12:03 2011 -0500
@@ -173,6 +173,7 @@
void unset_cache_entry();
void set_tbe(TBE a);
void unset_tbe();
+ void wakeUpBuffers(Address a);
// ** OBJECTS **
@@ -1013,7 +1014,7 @@
}
action(k_wakeUpDependents, k, desc=wake-up dependents) {
-wake_up_dependents(address);
+wakeUpBuffers(address);
}
action(l_popMemQueue, q, desc=Pop off-chip request queue) {
diff -r f3d1493787d4 -r 099771c7725d
src/mem/slicc/ast/WakeUpDependentsStatementAST.py
--- a/src/mem/slicc/ast/WakeUpDependentsStatementAST.py Fri Mar 18 14:12:01
2011 -0500
+++ /dev/null Thu Jan 01 00:00:00 1970 +
@@ -1,46 +0,0 @@
-# Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# 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.
-
-from slicc.ast.StatementAST import StatementAST
-
-class WakeUpDependentsStatementAST(StatementAST):
-def __init__(self, slicc, address):
-super(StatementAST, self).__init__(slicc)
-
[m5-dev] changeset in m5: SLICC: Remove external_type for structures
changeset 9a6a02a235f1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9a6a02a235f1
description:
SLICC: Remove external_type for structures
In SLICC, in order to define a type a data type for which it should not
generate any code, the keyword external_type is used. For those data
types for
which code should be generated, the keyword structure is used. This
patch
eliminates the use of keyword external_type for defining structures.
structure
key word can now have an optional attribute external, which would be
used for
figuring out whether or not to generate the code for this structure.
Also, now
structures can have functions as well data members in them.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 2 +-
src/mem/protocol/MESI_CMP_directory-L2cache.sm | 2 +-
src/mem/protocol/MESI_CMP_directory-dir.sm | 2 +-
src/mem/protocol/MESI_CMP_directory-dma.sm | 2 +-
src/mem/protocol/MI_example-cache.sm| 2 +-
src/mem/protocol/MI_example-dir.sm | 2 +-
src/mem/protocol/MOESI_CMP_directory-L1cache.sm | 2 +-
src/mem/protocol/MOESI_CMP_directory-L2cache.sm | 4 +-
src/mem/protocol/MOESI_CMP_directory-dir.sm | 2 +-
src/mem/protocol/MOESI_CMP_directory-dma.sm | 4 +-
src/mem/protocol/MOESI_CMP_token-L1cache.sm | 4 +-
src/mem/protocol/MOESI_CMP_token-L2cache.sm | 4 +-
src/mem/protocol/MOESI_CMP_token-dir.sm | 4 +-
src/mem/protocol/MOESI_CMP_token-dma.sm | 2 +-
src/mem/protocol/MOESI_hammer-cache.sm | 2 +-
src/mem/protocol/MOESI_hammer-dir.sm| 2 +-
src/mem/protocol/RubySlicc_Exports.sm | 2 +-
src/mem/protocol/RubySlicc_Types.sm | 25 +--
src/mem/slicc/parser.py | 26 +---
19 files changed, 38 insertions(+), 57 deletions(-)
diffs (truncated from 388 to 300 lines):
diff -r 099771c7725d -r 9a6a02a235f1
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smFri Mar 18 14:12:03
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smFri Mar 18 14:12:04
2011 -0500
@@ -119,7 +119,7 @@
int pendingAcks, default=0, desc=number of pending acks;
}
- external_type(TBETable) {
+ structure(TBETable, external=yes) {
TBE lookup(Address);
void allocate(Address);
void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smFri Mar 18 14:12:03
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smFri Mar 18 14:12:04
2011 -0500
@@ -145,7 +145,7 @@
int pendingAcks,desc=number of pending acks for invalidates
during writeback;
}
- external_type(TBETable) {
+ structure(TBETable, external=yes) {
TBE lookup(Address);
void allocate(Address);
void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MESI_CMP_directory-dir.sm
--- a/src/mem/protocol/MESI_CMP_directory-dir.smFri Mar 18 14:12:03
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-dir.smFri Mar 18 14:12:04
2011 -0500
@@ -95,7 +95,7 @@
int Len, desc=...;
}
- external_type(TBETable) {
+ structure(TBETable, external=yes) {
TBE lookup(Address);
void allocate(Address);
void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MESI_CMP_directory-dma.sm
--- a/src/mem/protocol/MESI_CMP_directory-dma.smFri Mar 18 14:12:03
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-dma.smFri Mar 18 14:12:04
2011 -0500
@@ -20,7 +20,7 @@
Ack, desc=DMA write to memory completed;
}
- external_type(DMASequencer) {
+ structure(DMASequencer, external=yes) {
void ackCallback();
void dataCallback(DataBlock);
}
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MI_example-cache.sm
--- a/src/mem/protocol/MI_example-cache.sm Fri Mar 18 14:12:03 2011 -0500
+++ b/src/mem/protocol/MI_example-cache.sm Fri Mar 18 14:12:04 2011 -0500
@@ -61,7 +61,7 @@
DataBlock DataBlk, desc=data for the block, required for concurrent
writebacks;
}
- external_type(TBETable) {
+ structure(TBETable, external=yes) {
TBE lookup(Address);
void allocate(Address);
void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MI_example-dir.sm
--- a/src/mem/protocol/MI_example-dir.smFri Mar 18 14:12:03 2011 -0500
+++ b/src/mem/protocol/MI_example-dir.smFri Mar 18 14:12:04 2011 -0500
@@ -66,7 +66,7 @@
MachineID DmaRequestor, desc=DMA requestor;
}
- external_type(TBETable) {
+ structure(TBETable, external=yes) {
TBE lookup(Address);
void allocate(Address);
void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1
[m5-dev] Review Request: Ruby: Convert CacheRequestType to RubyRequestType
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/602/ --- Review request for Default. Summary --- Ruby: Convert CacheRequestType to RubyRequestType This patch converts CacheRequestType to RubyRequestType so that both the protocol dependent and independent code makes use of the same request type. Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 9a6a02a235f1 src/mem/protocol/MI_example-cache.sm 9a6a02a235f1 src/mem/protocol/MOESI_CMP_directory-L1cache.sm 9a6a02a235f1 src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1 src/mem/protocol/MOESI_hammer-cache.sm 9a6a02a235f1 src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1 src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1 src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1 src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1 src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1 src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1 src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1 src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1 src/mem/ruby/profiler/Profiler.cc 9a6a02a235f1 src/mem/ruby/recorder/CacheRecorder.hh 9a6a02a235f1 src/mem/ruby/recorder/Tracer.hh 9a6a02a235f1 src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1 src/mem/ruby/slicc_interface/RubyRequest.cc 9a6a02a235f1 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 9a6a02a235f1 src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1 src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1 src/mem/ruby/system/DMASequencer.cc 9a6a02a235f1 src/mem/ruby/system/Sequencer.hh 9a6a02a235f1 src/mem/ruby/system/Sequencer.cc 9a6a02a235f1 Diff: http://reviews.m5sim.org/r/602/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
On Fri, 18 Mar 2011, Lisa Hsu wrote: What's going on with this patch? I don't believe it's been committed but it seems like it should. I've also got some patches waiting behind this because they used to touch CacheMsg and I don't want to mess Nilay up, so I've been waiting to serialize behind this. Lisa Lisa, the original patch was pretty long and after some of the changes that Brad submitted, almost the whole of the patch required rework. I have already committed some parts of the original patch. I have posted two more patches on the review board that cover some more portion of the patch. You can ignore the original patch. Assume that I will not post more patches that touch CacheMsg or related structures apart from the two that I posted 5 minutes ago. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Fri, 11 Mar 2011, Steve Reinhardt wrote: Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. There are more dependencies involved in here. RubySystem needs total memory size, which is calculated by looping through all the directory controllers. But the controllers themselves require RubySystem pointer. I still don't understand the opposition to cache controllers moving under RubySystem. They should logically be under RubySystem. Whenever we choose to remove RubySystem, everything will move under system. By having controllers under system and rest of Ruby components under RubySystem, we are creating two paths in the graph that are running parallel to each other, even though we have dependence between them. I would rather have a tree / directed acyclic structure. Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: SLICC: Remove the keyword wake_up_all_dependents
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/574/ --- Review request for Default. Summary --- SLICC: Remove the keyword wake_up_all_dependents In order to add stall and wait facility for protocols, a keyword wake_up_all_dependents was introduced. This patch removes the keyword, instead this functionality is now implemented as function call. Diffs - src/mem/protocol/MOESI_CMP_token-L1cache.sm 5138d1e453f1 src/mem/protocol/MOESI_hammer-cache.sm 5138d1e453f1 src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py 5138d1e453f1 src/mem/slicc/parser.py 5138d1e453f1 src/mem/slicc/symbols/StateMachine.py 5138d1e453f1 Diff: http://reviews.m5sim.org/r/574/diff Testing --- Both MOESI Hammer and Token have been compiled and tested with random tester. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Sat, 12 Mar 2011, Steve Reinhardt wrote: On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: On Fri, 11 Mar 2011, Steve Reinhardt wrote: Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. There are more dependencies involved in here. RubySystem needs total memory size, which is calculated by looping through all the directory controllers. But the controllers themselves require RubySystem pointer. Can't we loop through the directory controllers in python to calculate the total size, then pass that size as a parameter to RubySystem? There's no reason for the C++ RubySystem object to need the directory controller pointers just to do that calculation. It is being done in Python script. We were thinking of passing RubySystem object to the Network. But RubySystem cannot be created before directory controllers are created. And the reason for these changes is to pass RubySystem object to the controllers. I still don't understand the opposition to cache controllers moving under RubySystem. They should logically be under RubySystem. Whenever we choose to remove RubySystem, everything will move under system. By having controllers under system and rest of Ruby components under RubySystem, we are creating two paths in the graph that are running parallel to each other, even though we have dependence between them. I would rather have a tree / directed acyclic structure. Yes, it's supposed to be an acyclic tree structure. What do you mean by cache controllers moving under RubySystem? As children or as parameters? They're not parameters of System now, and the fact that they're children of System isn't related to the parameter cycle we're trying to break. I would like to access cache controllers from RubySystem parameter object in C++. If we do allow such access, then we would not have any cycle in the graph. We only need to create controllers, then network and then RubySystem in Python. If controllers are visible to RubySystem as members of the RubySystem parameter object, then we can create the list of cache memories by probing each controller object. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
Steve, here is the output after putting in the print statements. Creating root params Creating root Done creating root Creating system params Creating system Done creating system Creating system.l1_cntrl0 params Nilay On Wed, 9 Mar 2011, Steve Reinhardt wrote: It seems odd that it tries to create L1DcacheMemory right after it creates system. Can you add print statements like in this patch and see what it shows? diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py --- a/src/python/m5/SimObject.py +++ b/src/python/m5/SimObject.py @@ -843,8 +843,11 @@ # Call C++ to create C++ object corresponding to this object def createCCObject(self): +print Creating, self, params self.getCCParams() +print Creating, self self.getCCObject() # force creation +print Done creating, self def getValue(self): return self.getCCObject() On Wed, Mar 9, 2011 at 2:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Creating root Creating system.physmem Creating system Creating system.l1_cntrl0.L1DcacheMemory Creating system.ruby Creating system.ruby.network Creating system.ruby.network.topology Creating system.ruby.network.topology.ext_links0 Creating system.l1_cntrl0 Creating system.l1_cntrl0.L1DcacheMemory This is the output I obtained from SimObject.py, clearly there is a cycle. Should not the cache controllers be part of ruby, instead of being part of system? Once they become part of ruby, it should be possible to traverse the controller array and figure out all the caches. Nilay On Wed, 9 Mar 2011, Steve Reinhardt wrote: I think you're looking in the wrong place... you want to look at getCCObject() in src/python/m5/SimObject.py where the error message is coming from, and see if you can add some print statements there. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
I had originally put a print statement in getCCObject(), so using the word 'Creating' might have been mis-leading. For the previous output that I sent, I had removed that statement. What follows is patch and then the output -- diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py --- a/src/python/m5/SimObject.py +++ b/src/python/m5/SimObject.py @@ -821,6 +821,7 @@ # necessary to construct it. Does *not* recursively create # children. def getCCObject(self): +print Getting %s % self.path() if not self._ccObject: # Make sure this object is in the configuration hierarchy if not self._parent and not isRoot(self): @@ -843,8 +844,11 @@ # Call C++ to create C++ object corresponding to this object def createCCObject(self): +print Creating , self, params self.getCCParams() +print Creating , self self.getCCObject() # force creation +print Done creating , self def getValue(self): return self.getCCObject() -- Creating root params Creating root Getting root Done creating root Creating system params Getting system.physmem Creating system Getting system Done creating system Creating system.physmem params Creating system.physmem Getting system.physmem Done creating system.physmem Creating system.ruby params Getting system.ruby.network Getting system.ruby.network.topology Getting system.ruby.network.topology.ext_links0 Getting system.ruby.l1_cntrl0 Getting system.ruby.l1_cntrl0.L1DcacheMemory Getting system.ruby Getting system.ruby.network -- Nilay On Thu, 10 Mar 2011, Steve Reinhardt wrote: Is that it? It seems like there should be more output than from your previous example, not less... On Thu, Mar 10, 2011 at 5:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Steve, here is the output after putting in the print statements. Creating root params Creating root Done creating root Creating system params Creating system Done creating system Creating system.l1_cntrl0 params Nilay On Wed, 9 Mar 2011, Steve Reinhardt wrote: It seems odd that it tries to create L1DcacheMemory right after it creates system. Can you add print statements like in this patch and see what it shows? diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py --- a/src/python/m5/SimObject.py +++ b/src/python/m5/SimObject.py @@ -843,8 +843,11 @@ # Call C++ to create C++ object corresponding to this object def createCCObject(self): +print Creating, self, params self.getCCParams() +print Creating, self self.getCCObject() # force creation +print Done creating, self def getValue(self): return self.getCCObject() On Wed, Mar 9, 2011 at 2:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Creating root Creating system.physmem Creating system Creating system.l1_cntrl0.L1DcacheMemory Creating system.ruby Creating system.ruby.network Creating system.ruby.network.topology Creating system.ruby.network.topology.ext_links0 Creating system.l1_cntrl0 Creating system.l1_cntrl0.L1DcacheMemory This is the output I obtained from SimObject.py, clearly there is a cycle. Should not the cache controllers be part of ruby, instead of being part of system? Once they become part of ruby, it should be possible to traverse the controller array and figure out all the caches. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
I made some changes to MESI_CMP_directory.py and those changes are reflected in the output. The l1 and l2 controllers are now being attached to ruby instead of system. Nilay On Thu, 10 Mar 2011, Nilay Vaish wrote: I had originally put a print statement in getCCObject(), so using the word 'Creating' might have been mis-leading. For the previous output that I sent, I had removed that statement. What follows is patch and then the output -- diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py --- a/src/python/m5/SimObject.py +++ b/src/python/m5/SimObject.py @@ -821,6 +821,7 @@ # necessary to construct it. Does *not* recursively create # children. def getCCObject(self): +print Getting %s % self.path() if not self._ccObject: # Make sure this object is in the configuration hierarchy if not self._parent and not isRoot(self): @@ -843,8 +844,11 @@ # Call C++ to create C++ object corresponding to this object def createCCObject(self): +print Creating , self, params self.getCCParams() +print Creating , self self.getCCObject() # force creation +print Done creating , self def getValue(self): return self.getCCObject() -- Creating root params Creating root Getting root Done creating root Creating system params Getting system.physmem Creating system Getting system Done creating system Creating system.physmem params Creating system.physmem Getting system.physmem Done creating system.physmem Creating system.ruby params Getting system.ruby.network Getting system.ruby.network.topology Getting system.ruby.network.topology.ext_links0 Getting system.ruby.l1_cntrl0 Getting system.ruby.l1_cntrl0.L1DcacheMemory Getting system.ruby Getting system.ruby.network -- Nilay On Thu, 10 Mar 2011, Steve Reinhardt wrote: Is that it? It seems like there should be more output than from your previous example, not less... On Thu, Mar 10, 2011 at 5:36 AM, Nilay Vaish ni...@cs.wisc.edu wrote: Steve, here is the output after putting in the print statements. Creating root params Creating root Done creating root Creating system params Creating system Done creating system Creating system.l1_cntrl0 params Nilay On Wed, 9 Mar 2011, Steve Reinhardt wrote: It seems odd that it tries to create L1DcacheMemory right after it creates system. Can you add print statements like in this patch and see what it shows? diff --git a/src/python/m5/SimObject.py b/src/python/m5/SimObject.py --- a/src/python/m5/SimObject.py +++ b/src/python/m5/SimObject.py @@ -843,8 +843,11 @@ # Call C++ to create C++ object corresponding to this object def createCCObject(self): +print Creating, self, params self.getCCParams() +print Creating, self self.getCCObject() # force creation +print Done creating, self def getValue(self): return self.getCCObject() On Wed, Mar 9, 2011 at 2:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: Creating root Creating system.physmem Creating system Creating system.l1_cntrl0.L1DcacheMemory Creating system.ruby Creating system.ruby.network Creating system.ruby.network.topology Creating system.ruby.network.topology.ext_links0 Creating system.l1_cntrl0 Creating system.l1_cntrl0.L1DcacheMemory This is the output I obtained from SimObject.py, clearly there is a cycle. Should not the cache controllers be part of ruby, instead of being part of system? Once they become part of ruby, it should be possible to traverse the controller array and figure out all the caches. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Object Initialization using Python
As I understand, we use Python objects to initialize C++ objects. Is it possible to pass a pointer to an array (dynamic sized) from Python to C++? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
