Re: [gem5-dev] Review Request: [mq]: FunctionalAccess.9.patch

2011-06-12 Thread Nilay Vaish

---
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

2011-06-12 Thread Nilay Vaish

---
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

2011-06-10 Thread Nilay Vaish
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

2011-06-09 Thread Nilay Vaish
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

2011-06-08 Thread Nilay Vaish

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

2011-06-08 Thread Nilay Vaish

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

2011-06-08 Thread Nilay Vaish

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

2011-06-08 Thread Nilay Vaish


 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...

2011-06-08 Thread Nilay Vaish
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

2011-06-07 Thread Nilay Vaish

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

2011-06-06 Thread Nilay Vaish

---
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

2011-06-06 Thread Nilay Vaish

---
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

2011-06-05 Thread Nilay Vaish
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

2011-06-04 Thread Nilay Vaish
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

2011-06-04 Thread Nilay Vaish
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

2011-06-03 Thread Nilay Vaish
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

2011-06-01 Thread Nilay Vaish

---
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

2011-06-01 Thread Nilay Vaish

---
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

2011-06-01 Thread Nilay Vaish

---
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

2011-06-01 Thread Nilay Vaish
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

2011-05-31 Thread Nilay Vaish

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

2011-05-28 Thread Nilay Vaish

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

2011-05-27 Thread Nilay Vaish

---
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

2011-05-26 Thread Nilay Vaish

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-...

2011-05-07 Thread Nilay Vaish
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

2011-05-07 Thread Nilay Vaish
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

2011-05-07 Thread Nilay Vaish
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

2011-05-07 Thread Nilay Vaish
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

2011-05-06 Thread Nilay Vaish

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

2011-05-06 Thread Nilay Vaish

---
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)

2011-04-20 Thread Nilay Vaish

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)

2011-04-20 Thread Nilay Vaish
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

2011-04-16 Thread Nilay Vaish
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

2011-04-16 Thread Nilay Vaish


 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

2011-04-16 Thread Nilay Vaish


 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

2011-04-16 Thread Nilay Vaish
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

2011-04-16 Thread Nilay Vaish

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

2011-04-15 Thread Nilay Vaish


 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

2011-04-14 Thread Nilay Vaish
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

2011-04-14 Thread Nilay Vaish


 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

2011-04-14 Thread Nilay Vaish


 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

2011-04-13 Thread Nilay Vaish


 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

2011-04-13 Thread Nilay Vaish

---
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

2011-04-11 Thread Nilay Vaish

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

2011-04-10 Thread Nilay Vaish
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

2011-04-09 Thread Nilay Vaish
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

2011-04-09 Thread Nilay Vaish

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

2011-04-07 Thread Nilay Vaish

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

2011-04-07 Thread Nilay Vaish
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

2011-04-07 Thread Nilay Vaish

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

2011-04-07 Thread Nilay Vaish

---
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

2011-04-06 Thread Nilay Vaish

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

2011-04-04 Thread Nilay Vaish


 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

2011-04-04 Thread Nilay Vaish


 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

2011-04-04 Thread Nilay Vaish

---
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?

2011-04-03 Thread Nilay Vaish

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

2011-04-03 Thread Nilay Vaish


 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

2011-04-02 Thread Nilay Vaish


 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

2011-04-02 Thread Nilay Vaish


 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

2011-04-02 Thread Nilay Vaish

---
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

2011-04-01 Thread Nilay Vaish


 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

2011-03-31 Thread Nilay Vaish
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.

2011-03-31 Thread Nilay Vaish

---
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.

2011-03-31 Thread Nilay Vaish

---
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.

2011-03-31 Thread Nilay Vaish

---
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.

2011-03-31 Thread Nilay Vaish

---
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.

2011-03-31 Thread Nilay Vaish

---
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.

2011-03-31 Thread Nilay Vaish

---
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

2011-03-31 Thread Nilay Vaish


 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.

2011-03-31 Thread Nilay Vaish


 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

2011-03-31 Thread Nilay Vaish

---
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

2011-03-30 Thread Nilay Vaish

---
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

2011-03-30 Thread Nilay Vaish

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?

2011-03-30 Thread Nilay Vaish
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

2011-03-29 Thread Nilay Vaish

---
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

2011-03-29 Thread Nilay Vaish
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

2011-03-28 Thread Nilay Vaish
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

2011-03-28 Thread Nilay Vaish

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?

2011-03-23 Thread Nilay Vaish

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?

2011-03-23 Thread Nilay Vaish

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

2011-03-22 Thread Nilay Vaish
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

2011-03-22 Thread Nilay Vaish

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...

2011-03-20 Thread Nilay Vaish
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

2011-03-20 Thread Nilay Vaish
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

2011-03-20 Thread Nilay Vaish

---
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

2011-03-20 Thread Nilay Vaish

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

2011-03-19 Thread Nilay Vaish
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

2011-03-19 Thread Nilay Vaish
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

2011-03-18 Thread Nilay Vaish
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

2011-03-18 Thread Nilay Vaish
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

2011-03-18 Thread Nilay Vaish
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

2011-03-18 Thread Nilay Vaish

---
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

2011-03-18 Thread Nilay Vaish

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

2011-03-12 Thread Nilay Vaish

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

2011-03-12 Thread Nilay Vaish

---
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


[m5-dev] Review Request: SLICC: Remove the keyword wake_up_dependents

2011-03-12 Thread Nilay Vaish

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/575/
---

Review request for Default.


Summary
---

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.


Diffs
-

  src/mem/protocol/MOESI_CMP_token-L1cache.sm 5138d1e453f1 
  src/mem/protocol/MOESI_hammer-cache.sm 5138d1e453f1 
  src/mem/protocol/MOESI_hammer-dir.sm 5138d1e453f1 
  src/mem/slicc/ast/WakeUpDependentsStatementAST.py 5138d1e453f1 
  src/mem/slicc/parser.py 5138d1e453f1 
  src/mem/slicc/symbols/StateMachine.py 5138d1e453f1 

Diff: http://reviews.m5sim.org/r/575/diff


Testing
---

Both MOESI CMP token and Hammer 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

2011-03-12 Thread Nilay Vaish

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

2011-03-10 Thread Nilay Vaish

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

2011-03-10 Thread Nilay Vaish
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

2011-03-10 Thread Nilay Vaish
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


  1   2   3   4   >