Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-12 14:55:53.667339) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently only the M5Port of RubyPort supports functional accesses. The support for functional through the PioPort will be added as a separate patch. The patch has been tested for MI, MOESI directory, MOESI hammer and MESI directory protocols. It seems that MOESI token protocol cannot support functional accesses with it current implementation, there seems to be some problem with the L2 cache controller. Diffs (updated) - configs/example/ruby_direct_test.py ac4da9f8ea80 configs/example/ruby_fs.py ac4da9f8ea80 configs/example/ruby_mem_test.py ac4da9f8ea80 configs/example/ruby_network_test.py ac4da9f8ea80 configs/example/ruby_random_test.py ac4da9f8ea80 configs/ruby/MESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MI_example.py ac4da9f8ea80 configs/ruby/MOESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MOESI_CMP_token.py ac4da9f8ea80 configs/ruby/MOESI_hammer.py ac4da9f8ea80 configs/ruby/Ruby.py ac4da9f8ea80 src/cpu/testers/memtest/memtest.hh ac4da9f8ea80 src/cpu/testers/memtest/memtest.cc ac4da9f8ea80 src/mem/packet.hh ac4da9f8ea80 src/mem/packet.cc ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L1cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L2cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-dir.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-dir.sm ac4da9f8ea80 src/mem/ruby/network/Network.cc ac4da9f8ea80 src/mem/ruby/network/Network.py ac4da9f8ea80 src/mem/ruby/profiler/Profiler.cc ac4da9f8ea80 src/mem/ruby/profiler/Profiler.py ac4da9f8ea80 src/mem/ruby/recorder/Tracer.cc ac4da9f8ea80 src/mem/ruby/recorder/Tracer.py ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.hh ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.cc PRE-CREATION src/mem/ruby/slicc_interface/Controller.py ac4da9f8ea80 src/mem/ruby/slicc_interface/SConscript ac4da9f8ea80 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py ac4da9f8ea80 src/mem/ruby/system/CacheMemory.hh ac4da9f8ea80 src/mem/ruby/system/CacheMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.hh ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.py ac4da9f8ea80 src/mem/ruby/system/RubyPort.hh ac4da9f8ea80 src/mem/ruby/system/RubyPort.cc ac4da9f8ea80 src/mem/ruby/system/RubySystem.py ac4da9f8ea80 src/mem/ruby/system/SConscript ac4da9f8ea80 src/mem/ruby/system/Sequencer.py ac4da9f8ea80 src/mem/ruby/system/System.hh ac4da9f8ea80 src/mem/ruby/system/System.cc ac4da9f8ea80 src/mem/slicc/ast/MemberExprAST.py ac4da9f8ea80 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: [mq]: FunctionalAccess.9.patch
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-12 14:55:00.907885) Review request for Default. Summary (updated) --- [mq]: FunctionalAccess.9.patch Diffs (updated) - configs/example/ruby_direct_test.py ac4da9f8ea80 configs/example/ruby_fs.py ac4da9f8ea80 configs/example/ruby_mem_test.py ac4da9f8ea80 configs/example/ruby_network_test.py ac4da9f8ea80 configs/example/ruby_random_test.py ac4da9f8ea80 configs/ruby/MESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MI_example.py ac4da9f8ea80 configs/ruby/MOESI_CMP_directory.py ac4da9f8ea80 configs/ruby/MOESI_CMP_token.py ac4da9f8ea80 configs/ruby/MOESI_hammer.py ac4da9f8ea80 configs/ruby/Ruby.py ac4da9f8ea80 src/cpu/testers/memtest/memtest.hh ac4da9f8ea80 src/cpu/testers/memtest/memtest.cc ac4da9f8ea80 src/mem/packet.hh ac4da9f8ea80 src/mem/packet.cc ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L1cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-L2cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_CMP_directory-dir.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-cache.sm ac4da9f8ea80 src/mem/protocol/MOESI_hammer-dir.sm ac4da9f8ea80 src/mem/ruby/network/Network.cc ac4da9f8ea80 src/mem/ruby/network/Network.py ac4da9f8ea80 src/mem/ruby/profiler/Profiler.cc ac4da9f8ea80 src/mem/ruby/profiler/Profiler.py ac4da9f8ea80 src/mem/ruby/recorder/Tracer.cc ac4da9f8ea80 src/mem/ruby/recorder/Tracer.py ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.hh ac4da9f8ea80 src/mem/ruby/slicc_interface/AbstractController.cc PRE-CREATION src/mem/ruby/slicc_interface/Controller.py ac4da9f8ea80 src/mem/ruby/slicc_interface/SConscript ac4da9f8ea80 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py ac4da9f8ea80 src/mem/ruby/system/CacheMemory.hh ac4da9f8ea80 src/mem/ruby/system/CacheMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.hh ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.cc ac4da9f8ea80 src/mem/ruby/system/DirectoryMemory.py ac4da9f8ea80 src/mem/ruby/system/RubyPort.hh ac4da9f8ea80 src/mem/ruby/system/RubyPort.cc ac4da9f8ea80 src/mem/ruby/system/RubySystem.py ac4da9f8ea80 src/mem/ruby/system/SConscript ac4da9f8ea80 src/mem/ruby/system/Sequencer.py ac4da9f8ea80 src/mem/ruby/system/System.hh ac4da9f8ea80 src/mem/ruby/system/System.cc ac4da9f8ea80 src/mem/slicc/ast/MemberExprAST.py ac4da9f8ea80 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Ruby: Token Coherence and Functional Access
Brad, in the token coherence protocol, the l2 cache controller moves from state O to I and sends data to the memory. I think this particular transition is may pose a problem in enabling functional accesses for the protocol. The problem, I think, is that both the directory and the cache controller are in stable states even though there is data travelling in the network. This means that both the controllers will allow a functional write to go ahead. But then the data will be over written by the value sent from the l2 controller to the directory controller. My understanding of the protocol implementation is close to \epsilon. I think this is what I observed today in the morning. Do think this understanding is correct? -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron /z/m5/regression/do-regression quick
Korey, try 'hg status'. It would list the set of files that are not being tracked. May be there is some file that should be committed and has not been. -- Nilay On Thu, 9 Jun 2011, Korey Sewell wrote: My local repo has this at the tip: hg tip changeset: 8342:77d12d8f7971 tag: tip user:Korey Sewell 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 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 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 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 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
[gem5-dev] changeset in gem5: Ruby: Correctly set access permissions for di...
changeset 30daf1dd5c91 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=30daf1dd5c91
description:
Ruby: Correctly set access permissions for directory entries
The access permissions for the directory entries are not being set
correctly.
This is because pointers are not used for handling directory entries.
function. get and set functions for access permissions have been added
to the
Controller state machine. The changePermission() function provided by
the
AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC
code once again. The set_permission() functionality has been removed.
NOTE: Each protocol will have to define these get and set functions in
order
to compile successfully.
diffstat:
src/mem/protocol/MESI_CMP_directory-L1cache.sm | 20
src/mem/protocol/MESI_CMP_directory-L2cache.sm | 21 -
src/mem/protocol/MESI_CMP_directory-dir.sm | 15 ++-
src/mem/protocol/MESI_CMP_directory-dma.sm | 7 +++
src/mem/protocol/MI_example-cache.sm | 20
src/mem/protocol/MI_example-dir.sm | 15 +++
src/mem/protocol/MI_example-dma.sm | 7 +++
src/mem/protocol/MOESI_CMP_directory-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-L2cache.sm| 20
src/mem/protocol/MOESI_CMP_directory-dir.sm| 14 ++
src/mem/protocol/MOESI_CMP_directory-dma.sm| 7 +++
src/mem/protocol/MOESI_CMP_token-L1cache.sm| 20
src/mem/protocol/MOESI_CMP_token-L2cache.sm| 15 +++
src/mem/protocol/MOESI_CMP_token-dir.sm| 15 ++-
src/mem/protocol/MOESI_CMP_token-dma.sm| 7 +++
src/mem/protocol/MOESI_hammer-cache.sm | 20
src/mem/protocol/MOESI_hammer-dir.sm | 15 ++-
src/mem/protocol/MOESI_hammer-dma.sm | 7 +++
src/mem/protocol/Network_test-cache.sm | 7 +++
src/mem/protocol/Network_test-dir.sm | 7 +++
src/mem/protocol/RubySlicc_Types.sm| 8 ++--
src/mem/ruby/slicc_interface/AbstractController.hh | 4
src/mem/slicc/ast/MethodCallExprAST.py | 8 +++-
src/mem/slicc/symbols/StateMachine.py | 17 -
24 files changed, 296 insertions(+), 20 deletions(-)
diffs (truncated from 604 to 300 lines):
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smWed Jun 08 11:58:09
2011 -0500
@@ -183,6 +183,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L1_TBEs[addr];
+if(is_valid(tbe)) {
+ return L1Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L1Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L1Cache_State_to_permission(state));
+}
+ }
+
Event mandatory_request_type_to_event(RubyRequestType type) {
if (type == RubyRequestType:LD) {
return Event:Load;
diff -r e39a9c0493ad -r 30daf1dd5c91
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 00:57:50
2011 -0700
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smWed Jun 08 11:58:09
2011 -0500
@@ -202,7 +202,6 @@
return L2Cache_State_to_string(getState(tbe, cache_entry, addr));
}
- // when is this called
void setState(TBE tbe, Entry cache_entry, Address addr, State state) {
// MUST CHANGE
@@ -215,6 +214,26 @@
}
}
+ AccessPermission getAccessPermission(Address addr) {
+TBE tbe := L2_TBEs[addr];
+if(is_valid(tbe)) {
+ return L2Cache_State_to_permission(tbe.TBEState);
+}
+
+Entry cache_entry := getCacheEntry(addr);
+if(is_valid(cache_entry)) {
+ return L2Cache_State_to_permission(cache_entry.CacheState);
+}
+
+return AccessPermission:NotPresent;
+ }
+
+ void setAccessPermission(Entry cache_entry, Address addr, State state) {
+if (is_valid(cache_entry)) {
+ cache_entry.changePermission(L2Cache_State_to_permission(state));
+}
+ }
+
Event L1Cache_request_type_to_event(CoherenceRequestType type, Address addr,
MachineID requestor, Entry cache_entry) {
if(type == CoherenceRequestType:GETS) {
diff -r e39a9c0493ad -r 30daf1dd5c91 src/mem/protoco
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
> On 2011-06-08 17:11:26, Brad Beckmann wrote: > > This looks fine to me. I assume that if a controller doesn't include a > > setPermission or getPermission function, the compiler error message is the > > same as when a controller doesn't specify a getState function. Correct? Currently SLICC does not output any error if set/getState() or set/getAccessPermission() are missing. But I have patch in the queue which enables catching these errors in SLICC. For now GCC outputs that a particular function has not been implemented. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/#review1301 --- On 2011-06-06 14:45:22, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/684/ > --- > > (Updated 2011-06-06 14:45:22) > > > Review request for Default. > > > Summary > --- > > Ruby: Correctly set access permissions for directory entries > The access permissions for the directory entries are not being set correctly. > This is because pointers are not used for handling directory entries. > function. get and set functions for access permissions have been added to the > Controller state machine. The changePermission() function provided by the > AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC > code once again. The set_permission() functionality has been removed. > > NOTE: Each protocol will have to define these get and set functions in order > to compile successfully. > > > Diffs > - > > src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 > src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 > src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 > src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 > src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 > src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 > src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 > src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 > src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 > > Diff: http://reviews.m5sim.org/r/684/diff > > > Testing > --- > > Passes regression tests and 1 loads with ruby random tester. > > > Thanks, > > Nilay > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 23:28, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
This compiles. However, if you do b->function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though function()
is private for class B, still it gets invoked using the pointer from class A. I
was not aware of this before.
Overriding and access visibility is orthogonal, you use class A pointer to
access its public function.
I won't term this is a overriding, the function that will be called would
be the one defined in class B, as 'function()' is a virtual member of
class A. But then, 'function()' is private to class B, so I would expect
some error to occur. I think the reason is that visibility is tested only
at compile time and never at run time.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
On 8 Jun 2011, at 19:09, Nilay Vaish wrote:
On Wed, 8 Jun 2011, Jack Harvard wrote:
When you declare your function private, you can't use instance.function() to
access it. Is it generating a compile time error?
On 8 Jun 2011, at 00:31, Nilay Vaish wrote:
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
I should say that my example program was not what I intended it to be. The main
function should look like --
int main()
{
B* b = new B();
A* a = b;
a->function();
return 0;
}
Now what would happen?
This compiles. However, if you do b->function(), you would get the same error
as your last example, due to the same reason.
It compiles and executes fine. What surprises me is that even though
function() is private for class B, still it gets invoked using the pointer
from class A. I was not aware of this before.
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Query on inheritance and virtual functions
On Wed, 8 Jun 2011, Jack Harvard wrote:
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
[gem5-dev] Query on inheritance and virtual functions
Consider the following class declarations --
class A
{
public:
virtual void function() = 0;
};
class B : public A
{
private:
void function();
}
int main()
{
B b;
b.function();
}
Will this code compile correctly?
--
Nilay
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-06-06 14: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] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-06-06 14:44:19.791924) Review request for Default. Summary (updated) --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. get and set functions for access permissions have been added to the Controller state machine. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. NOTE: Each protocol will have to define these get and set functions in order to compile successfully. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MI_example-cache.sm b9ba22cb23f2 src/mem/protocol/MI_example-dir.sm b9ba22cb23f2 src/mem/protocol/MI_example-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_directory-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L1cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-L2cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_CMP_token-dma.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-cache.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dir.sm b9ba22cb23f2 src/mem/protocol/MOESI_hammer-dma.sm b9ba22cb23f2 src/mem/protocol/Network_test-cache.sm b9ba22cb23f2 src/mem/protocol/Network_test-dir.sm b9ba22cb23f2 src/mem/protocol/RubySlicc_Types.sm b9ba22cb23f2 src/mem/ruby/slicc_interface/AbstractController.hh b9ba22cb23f2 src/mem/slicc/ast/MethodCallExprAST.py b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py b9ba22cb23f2 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] /z/m5/regression/do-regression --scratch all
We again had the same problem as yesterday, though it seems that all the regression tests run up to completion. Any suggestions on resolving this? scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh () 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. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build
Re: [gem5-dev] Cron /z/m5/regression/do-regression quick
Will clearing all the existing builds and starting afresh remove this issue? Can some one do this? -- Nilay On Sat, 4 Jun 2011, Steve Reinhardt wrote: It seems very strange... like at a high level it thinks there's a cycle, but when it goes to print out where it is it can't find one. I've never seen this myself; I wonder if it's a bug in the version of scons on zizzer (v0.98), as the machine I use has v.1.2.0. It is a little strange that we're building params structs for Ruby objects in ALPHA_SE though. Steve On Sat, Jun 4, 2011 at 6:41 AM, Nilay Vaish 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 () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L2Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L2Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L2Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/SPARC_FS/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/L1Cache_Controller.hh () in state up_to_date -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Cron /z/m5/regression/do-regression quick
Does any one has any idea what a dependency cycles is? This is what zizzer's log has. scons: *** Found dependency cycle(s): Internal Error: no cycle found for node build/ALPHA_SE/params/L1Cache_Controller.hh (at 0x412a680>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/Directory_Controller.hh (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 () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L2Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/DMA_Controller.hh (0x30ae9b90>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/Directory_Controller.hh (instance at 0x16ea8560>) in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/L1Cache_Controller.hh (0x3a89d518>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE/params/DMA_Controller.hh (0x4105ef0>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/Directory_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_token/params/L2Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/X86_SE/params/L1Cache_Controller.hh (0x30be19e0>) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/DMA_Controller.hh (0x34b024d0>) in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/L1Cache_Controller.hh (0x34cfcc20>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_CMP_directory/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ARM_SE/params/DMA_Controller.hh (0x3a7b16c8>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/DMA_Controller.hh (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 () in state up_to_date Internal Error: no cycle found for node build/X86_FS/params/Directory_Controller.hh (at 0x34b08ef0>) in state up_to_date Internal Error: no cycle found for node build/SPARC_FS/params/Directory_Controller.hh (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 () in state up_to_date Internal Error: no cycle found for node build/ALPHA_FS/params/L1Cache_Controller.hh (at 0x16ec7290>) in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/L1Cache_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MESI_CMP_directory/params/DMA_Controller.hh () in state up_to_date Internal Error: no cycle found for node build/ALPHA_SE_MOESI_hammer/params/L1Cache_Controller.hh () 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 passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby 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/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPH
[gem5-dev] changeset in m5: SLICC: Remove machine name as prefix to functions
changeset b9ba22cb23f2 in /z/repo/m5
details: http://repo.gem5.org/m5?cmd=changeset;node=b9ba22cb23f2
description:
SLICC: Remove machine name as prefix to functions
Currently, the machine name is appended before any of the functions
defined with in the sm files. This is not necessary and it also
means that these functions cannot be used outside the sm files.
This patch does away with the prefixes. Note that the generated
C++ files in which the code for these functions is present are
still named such that the machine name is the prefix.
diffstat:
src/mem/slicc/symbols/Func.py | 14 +++---
src/mem/slicc/symbols/StateMachine.py | 16
2 files changed, 15 insertions(+), 15 deletions(-)
diffs (74 lines):
diff -r 3a2aebf01bf3 -r b9ba22cb23f2 src/mem/slicc/symbols/Func.py
--- a/src/mem/slicc/symbols/Func.py Thu Jun 02 21:23:02 2011 -0700
+++ b/src/mem/slicc/symbols/Func.py Fri Jun 03 13:52:18 2011 -0500
@@ -37,15 +37,12 @@
self.param_strings = param_strings
self.body = body
self.isInternalMachineFunc = False
+self.c_ident = ident
-if machine is None:
-self.c_ident = ident
-elif "external" in self or "primitive" in self:
-self.c_ident = ident
+if machine is None or "external" in self or "primitive" in self:
+pass
else:
self.machineStr = str(machine)
-# Append with machine name
-self.c_ident = "%s_%s" % (self.machineStr, ident)
self.isInternalMachineFunc = True
def __repr__(self):
@@ -107,6 +104,9 @@
${{self.body}}
}
''')
-code.write(path, "%s.cc" % self.c_ident)
+if self.isInternalMachineFunc:
+code.write(path, "%s_%s.cc" % (self.machineStr,self.c_ident))
+else:
+code.write(path, "%s.cc" % self.c_ident)
__all__ = [ "Func" ]
diff -r 3a2aebf01bf3 -r b9ba22cb23f2 src/mem/slicc/symbols/StateMachine.py
--- a/src/mem/slicc/symbols/StateMachine.py Thu Jun 02 21:23:02 2011 -0700
+++ b/src/mem/slicc/symbols/StateMachine.py Fri Jun 03 13:52:18 2011 -0500
@@ -1071,13 +1071,13 @@
{
''')
if self.TBEType != None and self.EntryType != None:
-code('${ident}_State state = ${ident}_getState(m_tbe_ptr,
m_cache_entry_ptr, addr);')
+code('${ident}_State state = getState(m_tbe_ptr,
m_cache_entry_ptr, addr);')
elif self.TBEType != None:
-code('${ident}_State state = ${ident}_getState(m_tbe_ptr, addr);')
+code('${ident}_State state = getState(m_tbe_ptr, addr);')
elif self.EntryType != None:
-code('${ident}_State state = ${ident}_getState(m_cache_entry_ptr,
addr);')
+code('${ident}_State state = getState(m_cache_entry_ptr, addr);')
else:
-code('${ident}_State state = ${ident}_getState(addr);')
+code('${ident}_State state = getState(addr);')
code('''
${ident}_State next_state = state;
@@ -1115,15 +1115,15 @@
CLEAR_TRANSITION_COMMENT();
''')
if self.TBEType != None and self.EntryType != None:
-code('${ident}_setState(m_tbe_ptr, m_cache_entry_ptr, addr,
next_state);')
+code('setState(m_tbe_ptr, m_cache_entry_ptr, addr, next_state);')
code('set_permission(m_cache_entry_ptr,
${ident}_State_to_permission(next_state));')
elif self.TBEType != None:
-code('${ident}_setState(m_tbe_ptr, addr, next_state);')
+code('setState(m_tbe_ptr, addr, next_state);')
elif self.EntryType != None:
-code('${ident}_setState(m_cache_entry_ptr, addr, next_state);')
+code('setState(m_cache_entry_ptr, addr, next_state);')
code('set_permission(m_cache_entry_ptr,
${ident}_State_to_permission(next_state));')
else:
-code('${ident}_setState(addr, next_state);')
+code('setState(addr, next_state);')
code('''
} else if (result == TransitionResult_ResourceStall) {
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses
I had posted a review request, it is not appropriate to respond to it with these type of questions. These questions should be asked on gem5-users list. And now the answer to your question. We currently do not update GEMS code. And I do not think that there is any plan to do so in future. In fact, we advise users to move to gem5. -- Nilay On Thu, 2 Jun 2011, huangyongbing wrote: Hi. I am currently using GEMS and Simics. So I care about whether the corresponding codes are also updated in GEMS. -Yongbing Huang 发件人： Nilay Vaish 发送时间： 2011-06-02 09:57:40 收件人： Nilay Vaish; Default; Brad Beckmann; Steve Reinhardt; Gabe Black 抄送： 主题： Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-01 18:59:16.473427) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns "busy" which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs (updated) - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev___ gem5-dev mailing list gem5-dev@m5sim.org http:/
[gem5-dev] Review Request: SLICC: Add a check function for State Machine
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/723/ --- Review request for Default. Summary --- SLICC: Add a check function for State Machine This patch adds a function for State Machines that will check whether the provided description in the .sm files includes some of the required functions, like getState() and setState(). Diffs - src/mem/slicc/ast/MachineAST.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/723/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-01 18:59:39.117342) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns "busy" which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing (updated) --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-06-01 18:59:16.473427) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. There is one significant change from the previous version of the patch. In the previous version, during functional writes, only the cache memories were being checked. During testing I realized that some of the cache lines could reside in the TBEs. So, now the check is being done at the controller level. The controller has to provide a function called getAccessPermission() for functional accesses to be successful. The default implementation of the function returns "busy" which means that the functional access cannot proceed further. The patch has been tested only for 1 loads and processor count from 1 to 16. Diffs (updated) - configs/example/ruby_mem_test.py 681497e0356b configs/ruby/MESI_CMP_directory.py 681497e0356b configs/ruby/MI_example.py 681497e0356b configs/ruby/MOESI_CMP_directory.py 681497e0356b configs/ruby/MOESI_CMP_token.py 681497e0356b configs/ruby/MOESI_hammer.py 681497e0356b configs/ruby/Ruby.py 681497e0356b src/cpu/testers/memtest/memtest.hh 681497e0356b src/cpu/testers/memtest/memtest.cc 681497e0356b src/mem/packet.hh 681497e0356b src/mem/packet.cc 681497e0356b src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MI_example-cache.sm 681497e0356b src/mem/protocol/MI_example-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b src/mem/ruby/network/Network.cc 681497e0356b src/mem/ruby/network/Network.py 681497e0356b src/mem/ruby/profiler/Profiler.cc 681497e0356b src/mem/ruby/profiler/Profiler.py 681497e0356b src/mem/ruby/recorder/Tracer.cc 681497e0356b src/mem/ruby/recorder/Tracer.py 681497e0356b src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b src/mem/ruby/slicc_interface/Controller.py 681497e0356b src/mem/ruby/slicc_interface/SConscript 681497e0356b src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 681497e0356b src/mem/ruby/system/CacheMemory.hh 681497e0356b src/mem/ruby/system/CacheMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.hh 681497e0356b src/mem/ruby/system/DirectoryMemory.cc 681497e0356b src/mem/ruby/system/DirectoryMemory.py 681497e0356b src/mem/ruby/system/RubyPort.hh 681497e0356b src/mem/ruby/system/RubyPort.cc 681497e0356b src/mem/ruby/system/RubySystem.py 681497e0356b src/mem/ruby/system/SConscript 681497e0356b src/mem/ruby/system/Sequencer.py 681497e0356b src/mem/ruby/system/System.hh 681497e0356b src/mem/ruby/system/System.cc 681497e0356b src/mem/slicc/ast/MemberExprAST.py 681497e0356b src/mem/slicc/symbols/Func.py 681497e0356b src/mem/slicc/symbols/StateMachine.py 681497e0356b Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Functional Memory Accesses in Ruby
On Sat, 28 May 2011, Nilay Vaish wrote: Hi Brad I am trying to complete the patch on functional accesses in Ruby. I came across this problem while testing the patch for higher number of processors. I am working with MESI CMP directory protocol right now. So I will describe the problem in its context. Assume we are trying to functionally write some thing to block A. It is in state S_I in the L2 cache. When a block moves to state S_I from state SS, then the cache block in the cache is deallocated. Therefore, when viewed from the CacheMemory's perpespective, since the cache does not have block A, therefore, the L2 cache is of no consequence for this access. But the controller has a TBE for this block. And this TBE will have this block with AccessPermission:Busy. Also, there are L1 caches in the system that hold this block in S state. Now, as per the current condition for write functional accesses, if((num_busy == 0 && num_ro > 0) || num_rw == 1) this access would go ahead as num_busy would evaluate to 0 and num_ro would evaluate to some value greater than 0. But clearly we do not want this access to be performed since that state S_I is a busy state and no other cache holds the block in a read-write state. It seems to me that the controller should supply the function for deciding the access permissions, since it is possible that one the TBE holds the block. -- Nilay Brad, I went over the discussion that we had this morning. I think the getState() function cannot be used for extracting access permissions. This is because the getState() function needs pouinters to transaction buffer and cache entries, apart from the address. I think we should let the Controller provide a function for getting the access permissions. This function would be a virtual function declared in the AbstractController class, but would not be pure. The AbstractController implementation of the function would always return busy, so that functional accesses are not enabled at all for protocols that do not provide such a function. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Functional Memory Accesses in Ruby
Hi Brad I am trying to complete the patch on functional accesses in Ruby. I came across this problem while testing the patch for higher number of processors. I am working with MESI CMP directory protocol right now. So I will describe the problem in its context. Assume we are trying to functionally write some thing to block A. It is in state S_I in the L2 cache. When a block moves to state S_I from state SS, then the cache block in the cache is deallocated. Therefore, when viewed from the CacheMemory's perpespective, since the cache does not have block A, therefore, the L2 cache is of no consequence for this access. But the controller has a TBE for this block. And this TBE will have this block with AccessPermission:Busy. Also, there are L1 caches in the system that hold this block in S state. Now, as per the current condition for write functional accesses, if((num_busy == 0 && num_ro > 0) || num_rw == 1) this access would go ahead as num_busy would evaluate to 0 and num_ro would evaluate to some value greater than 0. But clearly we do not want this access to be performed since that state S_I is a busy state and no other cache holds the block in a read-write state. It seems to me that the controller should supply the function for deciding the access permissions, since it is possible that one the TBE holds the block. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- (Updated 2011-05-27 11:41:44.345753) Review request for Default. Summary (updated) --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. The patch has been updated to set permissions for all the five protocols. All the protocols compile and clears 1 loads. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MI_example-cache.sm dda2a88eb7c4 src/mem/protocol/MI_example-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_directory-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L1cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-L2cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_CMP_token-dir.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-cache.sm dda2a88eb7c4 src/mem/protocol/MOESI_hammer-dir.sm dda2a88eb7c4 src/mem/protocol/RubySlicc_Types.sm dda2a88eb7c4 src/mem/slicc/ast/MethodCallExprAST.py dda2a88eb7c4 src/mem/slicc/symbols/StateMachine.py dda2a88eb7c4 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] [m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
On Fri, 6 May 2011, Beckmann, Brad wrote: Hi Nilay, Yeah, pulling the State into the Machine makes sense to me. If I recall, my previous patch made it necessary that each machine included a state_declaration (previously the state enum). More tightly integrating the state to the machine seems to be a natural progression on that path. I understand moving the permission settings back to setState is the easiest way to make this work. However, it would be great if we could combine the setting of state and the setting of permission into one function call from the sm file. Thus we don't have to worry about the situation where one sets the state, but forgets to set the permission. That could lead to some random functional access failing and a very painful debug. Brad I was trying to recall why I had suggested pulling State in to the Machine. It seems the reasoning was that then the calls to the function *_State_to_Permission() can be shortened to State_to_Permission(). The problem with combining the setting state and the permission it seems would be that cache and directory entries are treated differently. Cache entries get supplied to set state as pointers, where as directory entries are sought within the function it self. I am currently in favor of going with what I submitted earlier so that functional access patch can get out of the way soon as possible. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request: slicc: add a protocol statement and an include statement
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/717/#review1261 --- Ship it! Looks fine to me. - Nilay On 2011-05-24 10:15:40, Nathan Binkert wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/717/ > --- > > (Updated 2011-05-24 10:15:40) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > slicc: add a protocol statement and an include statement > All protocols must specify their name > The include statement allows any file to include another file. > > > Diffs > - > > src/mem/protocol/MESI_CMP_directory.slicc 3f37cc5d25bc > src/mem/protocol/MI_example.slicc 3f37cc5d25bc > src/mem/protocol/MOESI_CMP_directory.slicc 3f37cc5d25bc > src/mem/protocol/MOESI_CMP_token.slicc 3f37cc5d25bc > src/mem/protocol/MOESI_hammer.slicc 3f37cc5d25bc > src/mem/protocol/Network_test.slicc 3f37cc5d25bc > src/mem/protocol/RubySlicc_interfaces.slicc 3f37cc5d25bc > src/mem/protocol/SConscript 3f37cc5d25bc > src/mem/slicc/main.py 3f37cc5d25bc > src/mem/slicc/parser.py 3f37cc5d25bc > > Diff: http://reviews.m5sim.org/r/717/diff > > > Testing > --- > > Quick Regressions, Compile everything > > > Thanks, > > Nathan > > ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [m5-dev] Adding m5 debug statements to SLICC
Koreay, DPRINTF already works in sm files. Use RubySlicc as the flag. You can also use error() and assert() functions which have the following prototypes -- void error(std::string msg); void assert(bool condition); -- Nilay On Fri, 6 May 2011, Korey Sewell wrote: I guess I should rephrase this question to this: What's the best way to expose a new function to be used in the *.sm SLICC files? On Fri, May 6, 2011 at 3:26 AM, Korey Sewell 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] Review Request: Ruby: Correctly set access permissions for directory entries
Korey, I don't think there will be any change in the simulation performance. I am not sure about stats. Brad, were the stats updated after you made the change? -- Nilay On Fri, 6 May 2011, Korey Sewell wrote: Nilay, can you explain the impact of that bug in terms of simulation performance? Are benchmarks running slower because of this change? Will regressions need to be updated? On Fri, May 6, 2011 at 8:13 PM, Beckmann, Brad 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [m5-users] Tracing does not work
Joel, I have pushed in the patch the removes the options trace-help and
trace-flags. But trace-start and trace-file work as before. You can use
them in conjunction with debug-flags.
--
Nilay
On Fri, 6 May 2011, Nilay Vaish wrote:
I was thinking og doing it since Nate is not around. I'll do it soon.
--
Nilay
On Fri, 6 May 2011, Joel Hestness wrote:
Hey Nilay,
It looks like the tracing ("debug") functionality is now working again,
but the M5 help message is still incorrect (and extremely misleading). For
instance, "trace-flags", and "trace-file" are still accepted, but they
don't
do anything now. They should be eliminated from the message. We're also
missing the equivalent of "trace-start" and "trace-file". Do you mind
cleaning that up?
Thanks,
Joel
PS. I haven't followed the tracing/debugging thread closely enough, but it
seems like "trace" and "debug" should be different things (though they are
currently implemented as the same thing). Is there a reason why we moved
over to "debug"?
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Trace: Remove the options trace-help and trace-...
changeset a6363c870af6 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a6363c870af6
description:
Trace: Remove the options trace-help and trace-flags
The options trace-help and trace-flags are no longer required. In there
place,
the options debug-help and debug-flags have been provided.
diffstat:
src/python/m5/main.py | 4
1 files changed, 0 insertions(+), 4 deletions(-)
diffs (14 lines):
diff -r 3c628a51f6e1 -r a6363c870af6 src/python/m5/main.py
--- a/src/python/m5/main.py Fri May 06 01:00:32 2011 -0700
+++ b/src/python/m5/main.py Sat May 07 07:38:36 2011 -0500
@@ -106,10 +106,6 @@
# Tracing options
group("Trace Options")
-option("--trace-help", action='store_true',
-help="Print help on trace flags")
-option("--trace-flags", metavar="FLAG[,FLAG]", action='append', split=',',
-help="Sets the flags for tracing (-FLAG disables a flag)")
option("--trace-start", metavar="TIME", type='int',
help="Start tracing at TIME (must be in ticks)")
option("--trace-file", metavar="FILE", default="cout",
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: Ruby: Correctly set access permissions for directory entries
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/684/ --- Review request for Default. Summary --- Ruby: Correctly set access permissions for directory entries The access permissions for the directory entries are not being set correctly. This is because pointers are not used for handling directory entries. function. The setState() function will once again set the permissions as well. But it would make use of the State_to_permission() function, instead of doing the analysis it used to do earlier. The changePermission() function provided by the AbstractEntry and AbstractCacheEntry classes has been exposed to SLICC code once again. The set_permission() functionality has been removed. I have done this only for the MESI protocol so far. Once we build a consensus one the changes, I will make changes to other protocols as well. As far as testing is concerned, the protocol compiles and clears 1 loads. I did not test any more than that. A point that I wanted to raise for discussion: I think we should pull State enum and the accompanying functions into the Machine it self. Brad, what do you think? Diffs - src/mem/protocol/MESI_CMP_directory-L1cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-L2cache.sm 3c628a51f6e1 src/mem/protocol/MESI_CMP_directory-dir.sm 3c628a51f6e1 src/mem/protocol/RubySlicc_Types.sm 3c628a51f6e1 src/mem/slicc/ast/MethodCallExprAST.py 3c628a51f6e1 src/mem/slicc/symbols/StateMachine.py 3c628a51f6e1 Diff: http://reviews.m5sim.org/r/684/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] [m5-users] Tracing does not work
I was thinking og doing it since Nate is not around. I'll do it soon.
--
Nilay
On Fri, 6 May 2011, Joel Hestness wrote:
Hey Nilay,
It looks like the tracing ("debug") functionality is now working again,
but the M5 help message is still incorrect (and extremely misleading). For
instance, "trace-flags", and "trace-file" are still accepted, but they don't
do anything now. They should be eliminated from the message. We're also
missing the equivalent of "trace-start" and "trace-file". Do you mind
cleaning that up?
Thanks,
Joel
PS. I haven't followed the tracing/debugging thread closely enough, but it
seems like "trace" and "debug" should be different things (though they are
currently implemented as the same thing). Is there a reason why we moved
over to "debug"?
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Trace not working
So, the following command should work. But I am still getting some error. ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --debug-help Base Flags: Traceback (most recent call last): File "", line 1, in ? File "/afs/cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/main.py", line 238, in main debug.help() File "/afs/cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/debug.py", line 35, in help for flag in flags.basic: AttributeError: 'AllFlags' object has no attribute 'basic' -- Nilay On Mon, 25 Apr 2011, Beckmann, Brad wrote: Hi Nilay, In one of Nate's recent patches he changed the name from trace-help to debug-help. Similarly the command line "trace-flag" is now "debug-flag". However, I am confused as well on how to add a new TraceFlag/DebugFlag. It seems that all the previous flags are still specified using the "TraceFlag()" function, but I can't seem to be able to specify a new one.Also to be consistent, should we change the name of the TraceFlag function to DebugFlag? Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Monday, April 25, 2011 2:59 PM To: m5-dev@m5sim.org Subject: [m5-dev] Trace not working On Mon, 25 Apr 2011, Nilay Vaish wrote: The option trace-help is not working currently. When I execute the following ./build/ALPHA_SE_MESI_CMP_directory/m5.debug --trace-help I get a list of all the m5 options. Can some one confirm this? Thanks Nilay Seems like trace facility is not working currently. I am getting the following error -- ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --trace-flag=ProtocolTrace,RubyPort --trace-start=254 --trace-file=Trace.1 ./configs/example/ruby_mem_test.py -n 16 --functional 99 M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Apr 25 2011 16:54:13 M5 started Apr 25 2011 16:55:21 M5 executing on ale-01.cs.wisc.edu command line: ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --trace-flag=ProtocolTrace,RubyPort --trace-start=254 --trace-file=Trace.1 ./configs/example/ruby_mem_test.py -n 16 --functional 99 Traceback (most recent call last): File "", line 1, in ? File "/afs/cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m 5/main.py", line 327, in main e = event.create(trace.enable, event.Event.Trace_Enable_Pri) AttributeError: 'module' object has no attribute 'Event_Trace_Enable_Pri' -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Trace not working
On Mon, 25 Apr 2011, Nilay Vaish wrote: The option trace-help is not working currently. When I execute the following ./build/ALPHA_SE_MESI_CMP_directory/m5.debug --trace-help I get a list of all the m5 options. Can some one confirm this? Thanks Nilay Seems like trace facility is not working currently. I am getting the following error -- ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --trace-flag=ProtocolTrace,RubyPort --trace-start=254 --trace-file=Trace.1 ./configs/example/ruby_mem_test.py -n 16 --functional 99 M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Apr 25 2011 16:54:13 M5 started Apr 25 2011 16:55:21 M5 executing on ale-01.cs.wisc.edu command line: ./build/ALPHA_SE_MESI_CMP_directory/m5.opt --trace-flag=ProtocolTrace,RubyPort --trace-start=254 --trace-file=Trace.1 ./configs/example/ruby_mem_test.py -n 16 --functional 99 Traceback (most recent call last): File "", line 1, in ? File "/afs/cs.wisc.edu/u/n/i/nilay/private/Architecture/GEM5/m5/src/python/m5/main.py", line 327, in main e = event.create(trace.enable, event.Event.Trace_Enable_Pri) AttributeError: 'module' object has no attribute 'Event_Trace_Enable_Pri' -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Trace Help
The option trace-help is not working currently. When I execute the following ./build/ALPHA_SE_MESI_CMP_directory/m5.debug --trace-help I get a list of all the m5 options. Can some one confirm this? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: base: include types.hh in base/stats/mysql.hh
changeset ea37585785ab in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ea37585785ab
description:
base: include types.hh in base/stats/mysql.hh
Due to certain changes made via changeset 8229, the compilation was
failing
in certain cases. The compiler pointed to base/stats/mysql.hh for not
naming
a certain types like uint64_t. To rectify this, base/types.hh is being
included in base/stats/mysql.hh.
diffstat:
src/base/stats/mysql.hh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diffs (11 lines):
diff -r de679a068dd8 -r ea37585785ab src/base/stats/mysql.hh
--- a/src/base/stats/mysql.hh Sat Apr 23 15:02:29 2011 -0700
+++ b/src/base/stats/mysql.hh Mon Apr 25 12:23:37 2011 -0500
@@ -37,6 +37,7 @@
#include
#include "base/stats/output.hh"
+#include "base/types.hh"
#include "config/use_mysql.hh"
namespace MySQL { class Connection; }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141> > > > > Why are you adding this function? SLICC already generates a similar > > function: getPermission(). > > > > Overall, I hope/think we can add functional access support without > > requiring any more changes to the protocol specific .sm files beyond the > > changeset: 8086:bf0335d98250 that I checked in a couple months ago. > > Nilay Vaish wrote: > How would you use the function that is generated by SLICC inside the > sm file? I am concerned about the visibility of the function. > > Brad Beckmann wrote: > You can certainly use a function that is generated by SLICC inside the sm > file. The 'trigger' function is one such example. > > However, I'm not clear why you need to do that? Specifically, why do you > need to explicitly set the permissions in the getCacheEntry function? I > beleive the controller's doTransition function already does that when a > transition successfully completes. > > Nilay Vaish wrote: > I checked the generated code. It seems that permissions are being > set only for the cache entries and not for the directory entries. > > Brad Beckmann wrote: > Really? You should see a call to set_permissions inside the > Directory_Transitions.cc file. For example, when I compile the MOESI_hammer > protocol, I see the set_permission call on line 51 in > Directory_Transitions.cc. > > > > Nilay Vaish wrote: > The permissions would be set for the probe filter entry and not for the > directory entry. The directory entry pointer is not passed around like > the cache entry or TBE pointer. > > Brad Beckmann wrote: > Doh! Yep, that is a problem. So what are the potential solutions: > > 1. Inside the setState functions for the DirectoryControllers, we also > call set_permission. This would require us to expose set_permissions to > SLICC similar to how trigger is exposed to SLICC. Certainly possilbe, but > not ideal. Especially because it will require directory controllers and > cache controllers to have different functionality in their setState functions. > 2. Instead of allowing an entry's state to be directly assigned in the > setState functions, make the state variable private, thus requiring a public > funciton to modify state. When SLICC generates the implementation of that > public function, have that function modify both the state and the permissions. > 3. Remove the m_permission field in all entries and just rely on > get_permission to return the current permissions for cache and directory > entries. I'm not sure how to do that unless we create an AbstractState class > so that the state can be accessed by the Ruby side. Do we want to make such > a change? > > If we can make it work, I would prefer the second solution. What do you > think? Do you see other potential solutions? If you agree that the second > solution is best, do you want to take a crack at it or would you like me to? > Since it is my patch that is broken, I feel responsible to fix it. However, > I'm fine with you making the fix as well. > > Nilay Vaish wrote: > 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. > > Brad Beckmann wrote: > I'm not proposing that we try to generate the entire > ::setState function. Instead, I'm just proposing making the > current _Entry::m_State function private and adding a > new _Entry::setState() function that sets the state and the > permissions. > > Yeah, definitely think it through before going ahead to implement any > solution. There may be some issues that I'm overlooking. Brad, I think we should chuck the call to set_permission from StateMachine.py. Instead, we can add statements that set permissions with in the setState() function. The call would make use of the StateToPermission() function which would be automatically generated as is done now. Is this acceptable? And is it feasible? - 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://revi
Re: [m5-dev] Error while compiling (changeset 8229)
On Wed, 20 Apr 2011, nathan binkert wrote:
Because that file is being included regardless. ?I'm actively trying
to squash all of these bugs and I'll be committing some changes soon.
This one is trivial to fix.
I can't reproduce this bug on my machine, even with USE_MYSQL=False.
Can you try the attached diff? If it works for you, feel free to
commit it. If it doesn't work, just fix it however you need to and
post a diff.
Nate
The bug exists in 8246. Following works for me -
diff -r a9d06c894afe src/base/stats/mysql.hh
--- a/src/base/stats/mysql.hh Wed Apr 20 18:45:03 2011 -0700
+++ b/src/base/stats/mysql.hh Thu Apr 21 15:28:29 2011 -0500
@@ -37,6 +37,7 @@
#include
#include "base/stats/output.hh"
+#include "base/types.hh"
#include "config/use_mysql.hh"
namespace MySQL { class Connection; }
--
Nilay___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Error while compiling (changeset 8229)
Nate, since I have provided the option USE_MYSQL=False, why should mysql.hh even come in to picture? -- Nilay On Wed, 20 Apr 2011, nathan binkert wrote: The solution is to #include "base/types.hh" in mysql.hh, but to be honest, I'm not sure how this is even happening. Perhaps you need to blow away your build directory and compile again. That said, I did not compile with USE_MYSQL=False, so this could just be a bug that shows up in that instance. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Error while compiling (changeset 8229)
I started compilation with 8241, and that has this problem. So I tried to bisect it and 8229 is the first changeset that has this problem. -- Nilay On Wed, 20 Apr 2011, nathan binkert wrote: You need changeset 8230. You need the sort includes changeset and the one following it that fixes bugs. Nate 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 ___ 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] Error while compiling (changeset 8229)
I am trying to compile m5 and the scons exits with errors. Following is the compilation command -- scons -j 12 CXX=g++44 CC=gcc44 USE_MYSQL=False RUBY=True build/ALPHA_SE_MESI_CMP_directory/m5.fast and errors In file included from build/ALPHA_SE_MESI_CMP_directory/python/swig/stats_wrap.cc:3163: build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:52: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:63: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:73: error: 'size_type' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:75: error: 'size_type' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:81: error: 'uint64_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:83: error: 'uint16_t' does not name a type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:156: error: ISO C++ forbids declaration of 'DistData' with no type build/ALPHA_SE_MESI_CMP_directory/base/stats/mysql.hh:156: error: expected ',' or '...' before '&' token The command works till changeset 8228. It fails on 8229, the one on sorting included files. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Bug in changeset 8225 or 8227
On Sat, 16 Apr 2011, nathan binkert wrote: What version of python are you using? It could be that that syntax wasn't available until 2.5 and you're using something older. I can't do anything about it right now because I'm about to leave on a hike. Nate Nate, it seems one of your checkins from yesterday has a bug. I receive the following message on executing any merculrial command. *** failed to import extension style from ./util/style.py: invalid syntax (file_types.py, line 143) -- Nilay I am using python version 2.4.3. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Bug in changeset 8225 or 8227
Nate, it seems one of your checkins from yesterday has a bug. I receive the following message on executing any merculrial command. *** failed to import extension style from ./util/style.py: invalid syntax (file_types.py, line 143) -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-15 15:57:28, Steve Reinhardt wrote:
> > configs/example/ruby_mem_test.py, line 98
> > <http://reviews.m5sim.org/r/611/diff/8/?file=11625#file11625line98>
> >
> > You probably don't want to commit this value, do you? If you want to
> > hardwire a number, I'd pick something more reasonable (somewhere between 10
> > and 25, just guessing).
I need to add a command line option for this. I can
put the default value as 10.
> On 2011-04-15 15:57:28, Steve Reinhardt wrote:
> > src/mem/packet.hh, line 109
> > <http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line109>
> >
> > I don't see much value in having separate error return codes for reads
> > and writes. I'd use a single code that ends in Error (like
> > FunctionalAccessError), and put it up a couple of lines with the other
> > Error codes.
I will make this change.
> On 2011-04-15 15:57:28, Steve Reinhardt wrote:
> > src/mem/packet.hh, line 622
> > <http://reviews.m5sim.org/r/611/diff/8/?file=11629#file11629line622>
> >
> > Way too much code duplication here :-). I think this works, correct?
> >
> > void
> > makeFunctionalResponse(bool success)
> > {
> > makeResponse();
> > if (!success) {
> > cmd = MemCmd::FunctionalAccessError;
> > }
> > }
> >
Will make the required changes.
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/#review1130
---
On 2011-04-13 14:29:01, Nilay Vaish wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/611/
> ---
>
> (Updated 2011-04-13 14:29:01)
>
>
> Review request for Default.
>
>
> Summary
> ---
>
> Ruby: Add support for functional accesses
> This patch is meant for implementing functional access support in Ruby.
> Currently, the patch does not functional accesses for the PioPort.
>
>
> Diffs
> -
>
> configs/example/ruby_mem_test.py 8b5f900233ee
> configs/ruby/MESI_CMP_directory.py 8b5f900233ee
> configs/ruby/Ruby.py 8b5f900233ee
> src/cpu/testers/memtest/memtest.cc 8b5f900233ee
> src/mem/packet.hh 8b5f900233ee
> src/mem/packet.cc 8b5f900233ee
> src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee
> src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee
> src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee
> src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee
> src/mem/ruby/network/Network.cc 8b5f900233ee
> src/mem/ruby/network/Network.py 8b5f900233ee
> src/mem/ruby/profiler/Profiler.cc 8b5f900233ee
> src/mem/ruby/profiler/Profiler.py 8b5f900233ee
> src/mem/ruby/recorder/Tracer.cc 8b5f900233ee
> src/mem/ruby/recorder/Tracer.py 8b5f900233ee
> src/mem/ruby/system/AbstractMemory.hh PRE-CREATION
> src/mem/ruby/system/AbstractMemory.cc PRE-CREATION
> src/mem/ruby/system/AbstractMemory.py PRE-CREATION
> src/mem/ruby/system/Cache.py 8b5f900233ee
> src/mem/ruby/system/CacheMemory.hh 8b5f900233ee
> src/mem/ruby/system/CacheMemory.cc 8b5f900233ee
> src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee
> src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee
> src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee
> src/mem/ruby/system/RubyPort.hh 8b5f900233ee
> src/mem/ruby/system/RubyPort.cc 8b5f900233ee
> src/mem/ruby/system/RubySystem.py 8b5f900233ee
> src/mem/ruby/system/SConscript 8b5f900233ee
> src/mem/ruby/system/Sequencer.cc 8b5f900233ee
> src/mem/ruby/system/Sequencer.py 8b5f900233ee
> src/mem/ruby/system/System.hh 8b5f900233ee
> src/mem/ruby/system/System.cc 8b5f900233ee
> src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee
>
> Diff: http://reviews.m5sim.org/r/611/diff
>
>
> Testing
> ---
>
> I have tested functional accesses with the ratio between functional
> and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
> 10:90, 1:99. It is working in all the cases.
>
>
> Thanks,
>
> Nilay
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141> > > > > Why are you adding this function? SLICC already generates a similar > > function: getPermission(). > > > > Overall, I hope/think we can add functional access support without > > requiring any more changes to the protocol specific .sm files beyond the > > changeset: 8086:bf0335d98250 that I checked in a couple months ago. > > Nilay Vaish wrote: > How would you use the function that is generated by SLICC inside the > sm file? I am concerned about the visibility of the function. > > Brad Beckmann wrote: > You can certainly use a function that is generated by SLICC inside the sm > file. The 'trigger' function is one such example. > > However, I'm not clear why you need to do that? Specifically, why do you > need to explicitly set the permissions in the getCacheEntry function? I > beleive the controller's doTransition function already does that when a > transition successfully completes. > > Nilay Vaish wrote: > I checked the generated code. It seems that permissions are being > set only for the cache entries and not for the directory entries. > > Brad Beckmann wrote: > Really? You should see a call to set_permissions inside the > Directory_Transitions.cc file. For example, when I compile the MOESI_hammer > protocol, I see the set_permission call on line 51 in > Directory_Transitions.cc. > > > > Nilay Vaish wrote: > The permissions would be set for the probe filter entry and not for the > directory entry. The directory entry pointer is not passed around like > the cache entry or TBE pointer. > > Brad Beckmann wrote: > Doh! Yep, that is a problem. So what are the potential solutions: > > 1. Inside the setState functions for the DirectoryControllers, we also > call set_permission. This would require us to expose set_permissions to > SLICC similar to how trigger is exposed to SLICC. Certainly possilbe, but > not ideal. Especially because it will require directory controllers and > cache controllers to have different functionality in their setState functions. > 2. Instead of allowing an entry's state to be directly assigned in the > setState functions, make the state variable private, thus requiring a public > funciton to modify state. When SLICC generates the implementation of that > public function, have that function modify both the state and the permissions. > 3. Remove the m_permission field in all entries and just rely on > get_permission to return the current permissions for cache and directory > entries. I'm not sure how to do that unless we create an AbstractState class > so that the state can be accessed by the Ruby side. Do we want to make such > a change? > > If we can make it work, I would prefer the second solution. What do you > think? Do you see other potential solutions? If you agree that the second > solution is best, do you want to take a crack at it or would you like me to? > Since it is my patch that is broken, I feel responsible to fix it. However, > I'm fine with you making the fix as well. I will think about it. IIRC, we had a discussion earlier as well whether setState() can be generated automatically by SLICC and we decided against it. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-13 14:29:01, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-13 14:29:01) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for implementing functional access support in Ruby. > Currently, the patch does not functional accesses for the PioPort. > > > Diffs > - > > configs/example/ruby_mem_test.py 8b5f900233ee > configs/ruby/MESI_CMP_directory.py 8b5f900233ee > configs/ruby/Ruby.py 8b5f900233ee > src/cpu/testers/memtest/memtest.cc 8b5f900233ee > src/mem/packet.hh 8b5f900233ee > src/mem/packet.cc 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L2cache
[m5-dev] Testing Ruby Memory Controller
Is there a tester for testing the functionality of Ruby's memory controller? Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141> > > > > Why are you adding this function? SLICC already generates a similar > > function: getPermission(). > > > > Overall, I hope/think we can add functional access support without > > requiring any more changes to the protocol specific .sm files beyond the > > changeset: 8086:bf0335d98250 that I checked in a couple months ago. > > Nilay Vaish wrote: > How would you use the function that is generated by SLICC inside the > sm file? I am concerned about the visibility of the function. > > Brad Beckmann wrote: > You can certainly use a function that is generated by SLICC inside the sm > file. The 'trigger' function is one such example. > > However, I'm not clear why you need to do that? Specifically, why do you > need to explicitly set the permissions in the getCacheEntry function? I > beleive the controller's doTransition function already does that when a > transition successfully completes. > > Nilay Vaish wrote: > I checked the generated code. It seems that permissions are being > set only for the cache entries and not for the directory entries. > > Brad Beckmann wrote: > Really? You should see a call to set_permissions inside the > Directory_Transitions.cc file. For example, when I compile the MOESI_hammer > protocol, I see the set_permission call on line 51 in > Directory_Transitions.cc. > > 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/
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141> > > > > Why are you adding this function? SLICC already generates a similar > > function: getPermission(). > > > > Overall, I hope/think we can add functional access support without > > requiring any more changes to the protocol specific .sm files beyond the > > changeset: 8086:bf0335d98250 that I checked in a couple months ago. > > Nilay Vaish wrote: > How would you use the function that is generated by SLICC inside the > sm file? I am concerned about the visibility of the function. > > Brad Beckmann wrote: > You can certainly use a function that is generated by SLICC inside the sm > file. The 'trigger' function is one such example. > > However, I'm not clear why you need to do that? Specifically, why do you > need to explicitly set the permissions in the getCacheEntry function? I > beleive the controller's doTransition function already does that when a > transition successfully completes. I checked the generated code. It seems that permissions are being set only for the cache entries and not for the directory entries. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-13 14:29:01, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-13 14:29:01) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for implementing functional access support in Ruby. > Currently, the patch does not functional accesses for the PioPort. > > > Diffs > - > > configs/example/ruby_mem_test.py 8b5f900233ee > configs/ruby/MESI_CMP_directory.py 8b5f900233ee > configs/ruby/Ruby.py 8b5f900233ee > src/cpu/testers/memtest/memtest.cc 8b5f900233ee > src/mem/packet.hh 8b5f900233ee > src/mem/packet.cc 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee > src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee > src/mem/ruby/network/Network.cc 8b5f900233ee > src/mem/ruby/network/Network.py 8b5f900233ee > src/mem/ruby/profiler/Profiler.cc 8b5f900233ee > src/mem/ruby/profiler/Profiler.py 8b5f900233ee > src/mem/ruby/recorder/Tracer.cc 8b5f900233ee > src/mem/ruby/recorder/Tracer.py 8b5f900233ee > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/AbstractMemory.py PRE-CREATION > src/mem/ruby/system/Cache.py 8b5f900233ee > src/mem/ruby/system/CacheMemory.hh 8b5f900233ee > src/mem/ruby/system/CacheMemory.cc 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee > src/mem/ruby/system/RubyPort.hh 8b5f900233ee > src/mem/ruby/system/RubyPort.cc 8b5f900233ee > src/mem/ruby/system/RubySystem.py 8b5f900233ee > src/mem/ruby/system/SConscript 8b5f900233ee > src/mem/ruby/system/Sequencer.cc 8b5f900233ee > src/mem/ruby/system/Sequencer.py 8b5f900233ee > src/mem/ruby/system/System.hh 8b5f900233ee > src/mem/ruby/system/System.cc 8b5f900233ee > src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > --- > > I have tested functional accesses with the ratio between functional > and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, > 10:90, 1:99. It is working in all the cases. > > > Thanks, > > Nilay > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Ruby patch touching classic memory system
Ali, Nate, Steve Can you go through this patch? I have made some changes to src/mem/packet.hh and src/mem/packet.cc files. http://reviews.m5sim.org/r/611/ Thanks Nilay On Thu, 14 Apr 2011, Nilay Vaish wrote: 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 13:43:26, Gabe Black wrote: > > Please fix these style issues, including the ones in this file I haven't > > explicitly pointed out. You should be using M5 style generally, but > > especially when your in M5 code. Also, please be sure to point this out to > > one of the classic memory system experts (Nate, Steve, or Ali) and get them > > to sign off. They might not see that this change touches outside of Ruby. Gabe, I made the changes that you had pointed. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1113 --- On 2011-04-13 14:29:01, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-13 14:29:01) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for implementing functional access support in Ruby. > Currently, the patch does not functional accesses for the PioPort. > > > Diffs > - > > configs/example/ruby_mem_test.py 8b5f900233ee > configs/ruby/MESI_CMP_directory.py 8b5f900233ee > configs/ruby/Ruby.py 8b5f900233ee > src/cpu/testers/memtest/memtest.cc 8b5f900233ee > src/mem/packet.hh 8b5f900233ee > src/mem/packet.cc 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee > src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee > src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee > src/mem/ruby/network/Network.cc 8b5f900233ee > src/mem/ruby/network/Network.py 8b5f900233ee > src/mem/ruby/profiler/Profiler.cc 8b5f900233ee > src/mem/ruby/profiler/Profiler.py 8b5f900233ee > src/mem/ruby/recorder/Tracer.cc 8b5f900233ee > src/mem/ruby/recorder/Tracer.py 8b5f900233ee > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/AbstractMemory.py PRE-CREATION > src/mem/ruby/system/Cache.py 8b5f900233ee > src/mem/ruby/system/CacheMemory.hh 8b5f900233ee > src/mem/ruby/system/CacheMemory.cc 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee > src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee > src/mem/ruby/system/RubyPort.hh 8b5f900233ee > src/mem/ruby/system/RubyPort.cc 8b5f900233ee > src/mem/ruby/system/RubySystem.py 8b5f900233ee > src/mem/ruby/system/SConscript 8b5f900233ee > src/mem/ruby/system/Sequencer.cc 8b5f900233ee > src/mem/ruby/system/Sequencer.py 8b5f900233ee > src/mem/ruby/system/System.hh 8b5f900233ee > src/mem/ruby/system/System.cc 8b5f900233ee > src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > --- > > I have tested functional accesses with the ratio between functional > and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, > 10:90, 1:99. It is working in all the cases. > > > Thanks, > > Nilay > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
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
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 14:29:01.423144) 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 (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] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-13 11:17:53.272247) Review request for Default. Summary (updated) --- Ruby: Add support for functional accesses This patch is meant for implementing functional access support in Ruby. Currently, the patch does not functional accesses for the PioPort. Diffs (updated) - configs/example/ruby_mem_test.py 8b5f900233ee configs/ruby/MESI_CMP_directory.py 8b5f900233ee configs/ruby/Ruby.py 8b5f900233ee src/cpu/testers/memtest/memtest.cc 8b5f900233ee src/mem/packet.hh 8b5f900233ee src/mem/packet.cc 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L1cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-L2cache.sm 8b5f900233ee src/mem/protocol/MESI_CMP_directory-dir.sm 8b5f900233ee src/mem/protocol/RubySlicc_Types.sm 8b5f900233ee src/mem/ruby/network/Network.cc 8b5f900233ee src/mem/ruby/network/Network.py 8b5f900233ee src/mem/ruby/profiler/Profiler.cc 8b5f900233ee src/mem/ruby/profiler/Profiler.py 8b5f900233ee src/mem/ruby/recorder/Tracer.cc 8b5f900233ee src/mem/ruby/recorder/Tracer.py 8b5f900233ee src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py 8b5f900233ee src/mem/ruby/system/CacheMemory.hh 8b5f900233ee src/mem/ruby/system/CacheMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.hh 8b5f900233ee src/mem/ruby/system/DirectoryMemory.cc 8b5f900233ee src/mem/ruby/system/DirectoryMemory.py 8b5f900233ee src/mem/ruby/system/RubyPort.hh 8b5f900233ee src/mem/ruby/system/RubyPort.cc 8b5f900233ee src/mem/ruby/system/RubySystem.py 8b5f900233ee src/mem/ruby/system/SConscript 8b5f900233ee src/mem/ruby/system/Sequencer.cc 8b5f900233ee src/mem/ruby/system/Sequencer.py 8b5f900233ee src/mem/ruby/system/System.hh 8b5f900233ee src/mem/ruby/system/System.cc 8b5f900233ee src/mem/slicc/ast/MemberExprAST.py 8b5f900233ee Diff: http://reviews.m5sim.org/r/611/diff Testing --- I have tested functional accesses with the ratio between functional and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50, 10:90, 1:99. It is working in all the cases. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-13 10:28:08, Brad Beckmann wrote: > > configs/example/ruby_mem_test.py, line 97 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11542#file11542line97> > > > > It seems that the following three parameters should not be hardcoded, > > but instead should be set using command line options. Hardcoding the > > atomic parameter to false still makes sense, since Ruby can handle atomic > > requests. Also we should update the comment above. I did not add that line. I am not even aware what the purpose of that line is. I'll dig into what the implication of setting issue_dmas to false is. I will update the comment. > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/cpu/testers/memtest/memtest.cc, line 401 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11545#file11545line401> > > > > Remove commented out line Done! > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/protocol/MESI_CMP_directory-L1cache.sm, line 141 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11548#file11548line141> > > > > Why are you adding this function? SLICC already generates a similar > > function: getPermission(). > > > > Overall, I hope/think we can add functional access support without > > requiring any more changes to the protocol specific .sm files beyond the > > changeset: 8086:bf0335d98250 that I checked in a couple months ago. How would you use the function that is generated by SLICC inside the sm file? I am concerned about the visibility of the function. > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/ruby/system/CacheMemory.cc, line 270 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11563#file11563line270> > > > > Why are you commenting this line out? If you think it is no longer > > needed, just remove it. If we remove it, can we guarentee that the > > permission is initialized to some value? For instance, do we know whether > > the "entry" constructor will allows initialize the value? I expect the state to decide what the permission should be. > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/ruby/system/System.hh, line 132 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11573#file11573line132> > > > > Why are these functions static? I'm concerned that declaring these > > static will unecessarily restrict using Ruby in multiple system simulation. > > Also from my understanding of the code, there is no need to make them > > static. Perhaps I'm missing something. My bad! I think I did that under the impression that static variables can only be referenced in static functions. > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/ruby/system/RubyPort.cc, line 302 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11568#file11568line302> > > > > Overall, I really like the comments you added in this file. They > > really help clarify what is going on here. Just one > > minor correction: change "Any copy" to "Any valid copy" Done! > On 2011-04-13 10:28:08, Brad Beckmann wrote: > > src/mem/ruby/system/DirectoryMemory.cc, line 246 > > <http://reviews.m5sim.org/r/611/diff/6/?file=11565#file11565line246> > > > > Please align this statement. I am removing this line. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review --- On 2011-04-12 16:35:34, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-12 16:35:34) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for aiding discussions on implementation of functional > access support in Ruby. > > > Diffs > - > > configs/example/ruby_mem_test.py cb1e137ac35e > configs/ruby/MESI_CMP_directory.py cb1e137ac35e > configs/ruby/Ruby.py cb1e137ac35e > src/cpu/testers/memtest/memtest.cc cb1e137ac35e > src/mem/packet.hh cb1e137ac35e > src/mem/packet.cc cb1e137ac35e > src/mem/protocol/MESI_CMP_directory-L1cache.sm cb1e137ac35e > src/mem/protocol/MESI_CMP_directory-L2cache.sm cb1e137ac35e > src/mem/protocol/MESI_CMP_directory-dir.sm cb1e137ac35e > src/mem/protocol/RubySlicc_Types.sm cb1e137ac35e > s
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 On Tue, 12 Apr 2011, 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.866577) Review request for Default. Summary (updated) --- 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
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-12 16:35:34.866577) Review request for Default. Summary (updated) --- 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/system/DirectoryMemory.hh cb1e137ac35e src/mem/ruby/system/DirectoryMemory.cc cb1e137ac35e src/mem/ruby/system/DirectoryMemory.py cb1e137ac35e src/mem/ruby/system/RubyPort.hh cb1e137ac35e src/mem/ruby/system/RubyPort.cc cb1e137ac35e src/mem/ruby/system/RubySystem.py cb1e137ac35e src/mem/ruby/system/SConscript cb1e137ac35e src/mem/ruby/system/Sequencer.cc cb1e137ac35e src/mem/ruby/system/Sequencer.py cb1e137ac35e src/mem/ruby/system/System.hh cb1e137ac35e src/mem/ruby/system/System.cc cb1e137ac35e src/mem/slicc/ast/MemberExprAST.py cb1e137ac35e Diff: http://reviews.m5sim.org/r/611/diff Testing (updated) --- 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: * * *
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-12 16:32:36.416633) Review request for Default. Summary (updated) --- * * * Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - 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/system/DirectoryMemory.hh cb1e137ac35e src/mem/ruby/system/DirectoryMemory.cc cb1e137ac35e src/mem/ruby/system/DirectoryMemory.py cb1e137ac35e src/mem/ruby/system/RubyPort.hh cb1e137ac35e src/mem/ruby/system/RubyPort.cc cb1e137ac35e src/mem/ruby/system/RubySystem.py cb1e137ac35e src/mem/ruby/system/SConscript cb1e137ac35e src/mem/ruby/system/Sequencer.cc cb1e137ac35e src/mem/ruby/system/Sequencer.py cb1e137ac35e src/mem/ruby/system/System.hh cb1e137ac35e src/mem/ruby/system/System.cc cb1e137ac35e src/mem/slicc/ast/MemberExprAST.py cb1e137ac35e 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] AccessPermission in AbstractEntry
On Mon, 11 Apr 2011, Beckmann, Brad wrote: Hi Nilay, Yes, that is a good point. We really just need the interface to the permission to be available from AbstractEntry. The variable itself doesn't really need to be there. However, to make that change, you'll need to modify how CacheMemory supports atomics. I will try to make this change later today. Could you elaborate on your directory controller question. I suspect that you are right and that only one type of directory controller can exist in a system, but why is that a problem? Brad Is it not possible that we have a protocol in which different directory controllers may behave differently? -- Nilay -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Nilay Vaish Sent: Sunday, April 10, 2011 2:12 AM To: m5-dev@m5sim.org Subject: [m5-dev] AccessPermission in AbstractEntry Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] AccessPermission in AbstractEntry
Brad, it seems like the m_Permission variable in AbstractEntry is not being used at all. In order to get AccessPermission for a state, the state_To_AccessPermission function needs to be called. Then, why have that variable? And this would mean that CacheMemory has no idea about the access permission, unless we expose the state to Cache Memory class. Also, as it now stands, it seems one cannot have two different types of directory controllers in a system. Is this correct? If yes, then why this restriction? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Testing Functional Access
Brad, 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_cast(ruby_request.pkt->senderState);
RubyTester::SenderState* testerSenderState =
(RubyTester::SenderState*)(requestSenderState->saved);
testerSenderState->subBlock->mergeFrom(data);
}
Thanks
Nilay
On Tue, 1 Mar 2011, Beckmann, Brad wrote:
I forgot that the memtester includes functional accesses. That is a good
suggestion, especially when it comes to testing the situations where Ruby
can't satisfy the functional access due to contention with timing accesses.
The memtester does run with Ruby (it actually runs every night in the
regression tester), however the percentage of functional accesses is
currently set to zero. See configs/example/ruby_mem_test.py. You'll
obviously want to change that and include code within
src/cpu/testers/memtest/* to handle failed functional accesses. If you
don't want to initially deal with the failure situations, you can set the
functional access percentage to 100% and that should always work.
Brad
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Testing Functional Access
Brad, 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_cast(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] Review Request: ruby: dbg: use system ticks instead of cycles
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/635/#review1102 --- src/mem/ruby/network/simple/PerfectSwitch.cc <http://reviews.m5sim.org/r/635/#comment1467> If DPRINTF() prints the time, is this piece of code required? src/mem/ruby/system/Sequencer.cc <http://reviews.m5sim.org/r/635/#comment1468> Again, do we need curTick() here? src/mem/ruby/system/Sequencer.cc <http://reviews.m5sim.org/r/635/#comment1469> Same comment as before. - Nilay On 2011-04-05 11:19:26, Korey Sewell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/635/ > --- > > (Updated 2011-04-05 11:19:26) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > ruby: dbg: use system ticks instead of cycles > It's easier to debug simulations (find the exact point to rerun a trace) when > the output is in > the system ticks instead of the Ruby cycle time > > > Diffs > - > > src/mem/ruby/buffers/MessageBuffer.cc 54a65799e4c1 > src/mem/ruby/network/simple/PerfectSwitch.cc 54a65799e4c1 > src/mem/ruby/system/Sequencer.cc 54a65799e4c1 > src/mem/slicc/symbols/StateMachine.py 54a65799e4c1 > src/mem/slicc/symbols/Type.py 54a65799e4c1 > > Diff: http://reviews.m5sim.org/r/635/diff > > > Testing > --- > > > Thanks, > > Korey > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
On Thu, 7 Apr 2011, Gabriel Michael Black wrote: Quoting 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 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] Running Ruby w/32 Cores
The problem is that LONG_BITS is 31, ie std::numeric_limits::digits
returns 31 and not 32 which is what the writer expected.
--
Nilay
From: koreylsew...@gmail.com [mailto:koreylsew...@gmail.com] On Behalf Of
Korey Sewell
Sent: Tuesday, April 05, 2011 7:14 AM
To: Beckmann, Brad
Subject: Re: [m5-dev] Running Ruby w/32 Cores
Hi again Brad, I looked this over again and although my 32-bit patch
"fixes" things, now that I look at it again, I'm not convinced that I
actually fixed the symptom of the bug but rather the cause of the bug.
Do you happen to know what are the problems with the 32-bit Set counts?
Sorry for prolonging the issue, but I thought I had put this to bed but
maybe not. Finally, it may not matter that this works on 32-bit machines
but it'd be nice if it did. (Let me know if I should move this convo to
the m5-dev list)
I end up checking the last bit in the count function manually (the code
as follows): int Set::count() const {
int counter = 0;
long mask;
for (int i = 0; i < m_nArrayLen; i++) {
mask = (long)0x01;
for (int j = 0; j < LONG_BITS; j++) {
// FIXME - significant performance loss when array
// population << LONG_BITS
if ((m_p_nArray[i] & mask) != 0) {
counter++;
}
mask = mask << 1;
}
#ifndef _LP64
long msb_mask = 0x8000;
if ((m_p_nArray[i] & msb_mask) != 0) {
counter++;
}
#endif
}
return counter;
}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Running Ruby w/32 Cores
On Thu, 7 Apr 2011, Gabriel Michael Black wrote: 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
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] Running Ruby w/32 Cores
I believe even popcount is portable. I am not opposed to using bitset,
just that it would probably require lot more changes.
--
Nilay
On Wed, 6 Apr 2011, Ali Saidi wrote:
stl::bitset does these type of optimizations underneath and it's portable.
Ali
On Wed, 6 Apr 2011 15:57:37 -0500 (CDT), Nilay Vaish
wrote:
I would prefer we make use of GCC builtin __builtin_popcount() for
counting the number of 1's in an int or related data type.
Nilay
On Wed, 6 Apr 2011, Ali Saidi wrote:
And actually, couldn't you use an stl bitset for this?
Thanks,
Ali
On Wed, 06 Apr 2011 15:34:01 -0500, Ali Saidi wrote:
Jumping in somewhat randomly here, uint64_t even on a 32bit machine
is reasonably fast. It's not going to be as fast, but it will be
correct. My vote would be to just switch all that Set code that uses
long to explicitly use uint64_t and if it's slower on a 32bit machine
so be it. At least it's correct.
Ali
On Wed, 6 Apr 2011 15:24:24 -0500, "Beckmann, Brad"
wrote:
Hi Korey,
Yes, let's move this conversation back to m5-dev, since I think
others may be interested and could help.
I don't know what the problem is exactly, but at some point of time
(probably back in the early GEMS days) I seem to remember the Set code
included an assertion check about the 31st bit in 32-bit mode.
Therefore, I think we knew about this problem and made sure that never
happened. I believe that is why we used to have a restriction that
Ruby could only support 16 processors. I'm really fuzzy on the
details...maybe someone else can elaborate.
In the end, I just want to make sure we add something in the code
that makes sure we don't encounter this problem again. This is one of
those bugs that can take a while to track down, if you don't catch it
right when it happens with an assertion.
Brad
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
___
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] Running Ruby w/32 Cores
I would prefer we make use of GCC builtin __builtin_popcount() for
counting the number of 1's in an int or related data type.
Nilay
On Wed, 6 Apr 2011, Ali Saidi wrote:
And actually, couldn't you use an stl bitset for this?
Thanks,
Ali
On Wed, 06 Apr 2011 15:34:01 -0500, Ali Saidi wrote:
Jumping in somewhat randomly here, uint64_t even on a 32bit machine
is reasonably fast. It's not going to be as fast, but it will be
correct. My vote would be to just switch all that Set code that uses
long to explicitly use uint64_t and if it's slower on a 32bit machine
so be it. At least it's correct.
Ali
On Wed, 6 Apr 2011 15:24:24 -0500, "Beckmann, Brad"
wrote:
Hi Korey,
Yes, let's move this conversation back to m5-dev, since I think
others may be interested and could help.
I don't know what the problem is exactly, but at some point of time
(probably back in the early GEMS days) I seem to remember the Set code
included an assertion check about the 31st bit in 32-bit mode.
Therefore, I think we knew about this problem and made sure that never
happened. I believe that is why we used to have a restriction that
Ruby could only support 16 processors. I'm really fuzzy on the
details...maybe someone else can elaborate.
In the end, I just want to make sure we add something in the code
that makes sure we don't encounter this problem again. This is one of
those bugs that can take a while to track down, if you don't catch it
right when it happens with an assertion.
Brad
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] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-04 06:22:20.346203) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - configs/ruby/MESI_CMP_directory.py aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/AbstractMemory.py PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-04-03 13:45:28, Brad Beckmann wrote: > > src/mem/ruby/system/DirectoryMemory.py, line 2 > > <http://reviews.m5sim.org/r/611/diff/4/?file=11465#file11465line2> > > > > Why are you deleting this file and where are you moving the current > > functionality? My bad! I had forgotten to add AbstractMemory.py file. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1090 ------- On 2011-04-02 11:42:47, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-02 11:42:47) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for aiding discussions on implementation of functional > access support in Ruby. > > > Diffs > - > > configs/ruby/MESI_CMP_directory.py aeec9e157d06 > configs/ruby/Ruby.py aeec9e157d06 > src/mem/ruby/network/Network.cc aeec9e157d06 > src/mem/ruby/network/Network.py aeec9e157d06 > src/mem/ruby/profiler/Profiler.cc aeec9e157d06 > src/mem/ruby/profiler/Profiler.py aeec9e157d06 > src/mem/ruby/recorder/Tracer.cc aeec9e157d06 > src/mem/ruby/recorder/Tracer.py aeec9e157d06 > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/Cache.py aeec9e157d06 > src/mem/ruby/system/CacheMemory.hh aeec9e157d06 > src/mem/ruby/system/CacheMemory.cc aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 > src/mem/ruby/system/RubyPort.hh aeec9e157d06 > src/mem/ruby/system/RubyPort.cc aeec9e157d06 > src/mem/ruby/system/RubySystem.py aeec9e157d06 > src/mem/ruby/system/SConscript aeec9e157d06 > src/mem/ruby/system/Sequencer.cc aeec9e157d06 > src/mem/ruby/system/Sequencer.py aeec9e157d06 > src/mem/ruby/system/System.hh aeec9e157d06 > src/mem/ruby/system/System.cc aeec9e157d06 > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > --- > > > Thanks, > > Nilay > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-03-31 22:08:21, Brad Beckmann wrote: > > This looks great, I just have a few minor suggestions below. > > > > It seems like the next step is to figure out how to deal with functional > > accesses not succeeding in the CPUs and devices. > > Nilay Vaish wrote: > Brad, I would make the changes you have listed below. I also need to add > code for directory memory accesses. Can you elaborate on the next step > you > mentioned? We are yet not dealing with the devices, I believe. > > Nilay Vaish wrote: > One more question for you. Do we need functional access support for the > PioPort > as well? We do not have it currently. > > Brad Beckmann wrote: > Yes, eventually if we want Ruby to supply data in FS mode, RubyPort will > need to support functional access from the PioPort to Ruby memory. It is up > to you whether you want to implement that support now, or first make sure > functional accesses are working SE mode. If you want to make sure SE mode > functional accesses work, first modify the ruby mem tester to issue > functional access (right now that is hardcoded off). Also you should try a > few binaries under SE mode, like "hello world". Brad, I'll test the current implementation first and then work on functional accesses from the PioPort. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1082 --- On 2011-04-02 11:42:47, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-04-02 11:42:47) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for aiding discussions on implementation of functional > access support in Ruby. > > > Diffs > - > > configs/ruby/MESI_CMP_directory.py aeec9e157d06 > configs/ruby/Ruby.py aeec9e157d06 > src/mem/ruby/network/Network.cc aeec9e157d06 > src/mem/ruby/network/Network.py aeec9e157d06 > src/mem/ruby/profiler/Profiler.cc aeec9e157d06 > src/mem/ruby/profiler/Profiler.py aeec9e157d06 > src/mem/ruby/recorder/Tracer.cc aeec9e157d06 > src/mem/ruby/recorder/Tracer.py aeec9e157d06 > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/Cache.py aeec9e157d06 > src/mem/ruby/system/CacheMemory.hh aeec9e157d06 > src/mem/ruby/system/CacheMemory.cc aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 > src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 > src/mem/ruby/system/RubyPort.hh aeec9e157d06 > src/mem/ruby/system/RubyPort.cc aeec9e157d06 > src/mem/ruby/system/RubySystem.py aeec9e157d06 > src/mem/ruby/system/SConscript aeec9e157d06 > src/mem/ruby/system/Sequencer.cc aeec9e157d06 > src/mem/ruby/system/Sequencer.py aeec9e157d06 > src/mem/ruby/system/System.hh aeec9e157d06 > src/mem/ruby/system/System.cc aeec9e157d06 > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > --- > > > Thanks, > > Nilay > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-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] Ruby Optimization Opportunity?
On Fri, 1 Apr 2011, Korey Sewell wrote: That's a good point. I'll coordinate with Nilay offline to get him the right image. Nilay, from your previous optimizations trials, where did you see most of the simulation time being sent at? On Fri, Apr 1, 2011 at 4:48 PM, Ali Saidi 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
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-04-02 11:42:47.195024) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - configs/ruby/MESI_CMP_directory.py aeec9e157d06 configs/ruby/Ruby.py aeec9e157d06 src/mem/ruby/network/Network.cc aeec9e157d06 src/mem/ruby/network/Network.py aeec9e157d06 src/mem/ruby/profiler/Profiler.cc aeec9e157d06 src/mem/ruby/profiler/Profiler.py aeec9e157d06 src/mem/ruby/recorder/Tracer.cc aeec9e157d06 src/mem/ruby/recorder/Tracer.py aeec9e157d06 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py aeec9e157d06 src/mem/ruby/system/CacheMemory.hh aeec9e157d06 src/mem/ruby/system/CacheMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.hh aeec9e157d06 src/mem/ruby/system/DirectoryMemory.cc aeec9e157d06 src/mem/ruby/system/DirectoryMemory.py aeec9e157d06 src/mem/ruby/system/RubyPort.hh aeec9e157d06 src/mem/ruby/system/RubyPort.cc aeec9e157d06 src/mem/ruby/system/RubySystem.py aeec9e157d06 src/mem/ruby/system/SConscript aeec9e157d06 src/mem/ruby/system/Sequencer.cc aeec9e157d06 src/mem/ruby/system/Sequencer.py aeec9e157d06 src/mem/ruby/system/System.hh aeec9e157d06 src/mem/ruby/system/System.cc aeec9e157d06 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-03-31 22:08:21, Brad Beckmann wrote: > > 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
> On 2011-04-01 09:30:54, Brad Beckmann wrote: > > Hi Nilay, Comments below. I might be missing something, but the changes to DirectoryMemory seem straightforward. No, you are not missing anything. It is just that I had not implemented it up till now. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1085 --- On 2011-03-31 20:44:17, Nilay Vaish wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/611/ > --- > > (Updated 2011-03-31 20:44:17) > > > Review request for Default. > > > Summary > --- > > Ruby: Add support for functional accesses > This patch is meant for aiding discussions on implementation of functional > access support in Ruby. > > > Diffs > - > > configs/ruby/MESI_CMP_directory.py c7302d55d644 > configs/ruby/Ruby.py c7302d55d644 > src/mem/ruby/network/Network.cc c7302d55d644 > src/mem/ruby/network/Network.py c7302d55d644 > src/mem/ruby/profiler/Profiler.cc c7302d55d644 > src/mem/ruby/profiler/Profiler.py c7302d55d644 > src/mem/ruby/recorder/Tracer.cc c7302d55d644 > src/mem/ruby/recorder/Tracer.py c7302d55d644 > src/mem/ruby/system/AbstractMemory.hh PRE-CREATION > src/mem/ruby/system/AbstractMemory.cc PRE-CREATION > src/mem/ruby/system/Cache.py c7302d55d644 > src/mem/ruby/system/CacheMemory.hh c7302d55d644 > src/mem/ruby/system/CacheMemory.cc c7302d55d644 > src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 > src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 > src/mem/ruby/system/DirectoryMemory.py c7302d55d644 > src/mem/ruby/system/RubyPort.hh c7302d55d644 > src/mem/ruby/system/RubyPort.cc c7302d55d644 > src/mem/ruby/system/RubySystem.py c7302d55d644 > src/mem/ruby/system/SConscript c7302d55d644 > src/mem/ruby/system/Sequencer.cc c7302d55d644 > src/mem/ruby/system/Sequencer.py c7302d55d644 > src/mem/ruby/system/System.hh c7302d55d644 > src/mem/ruby/system/System.cc c7302d55d644 > > Diff: http://reviews.m5sim.org/r/611/diff > > > Testing > --- > > > Thanks, > > Nilay > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-03-31 22:08:21, Brad Beckmann wrote: > > 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
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> On 2011-03-31 11:11:03, Brad Beckmann wrote: > > src/mem/ruby/system/RubyPort.cc, line 321 > > <http://reviews.m5sim.org/r/611/diff/2/?file=11382#file11382line321> > > > > This loop is probably the most complicated and important part of this > > patch. It might be easiest if we move this functionality into two > > different functions, one for reads and one for writes. > > > > The read scan just needs to ensure that at least one memory says that > > it has the address in Read_Only or ReadWrite state. We may also want to > > doublecheck that multiple memories say they have the address in ReadWrite > > state. > > > > The write scan is more complicated. If one memory says that it has the > > address in ReadWrite state, then I don't think it matters what state the > > other memories are in (except of course if another memory says it also has > > the address in ReadWrite), the write should succeed. Also if the write > > scans says that all copies are in Read_Only or Invalid/NotPresent state and > > no copies are Busy, the write should succeed. However, writes should fail > > if either no Read_Only or ReadWrite copies are found, or if a Busy copy is > > found and no ReadWrite copy is found. The latter situation will likely > > indicate the functional write is racing with a timing write. There is no > > easy, protocol-agnostic way to resolve such a race in the current > > infrastructure. > > > > Make sense? > > Nilay Vaish wrote: > I think we should have the following cases for functional writes -- > 1. Only read only copies --> write succeeds > 2. One read write copy --> write succeeds > 3. At least one busy --> write fails. > 4. None of the above, then simply update the memory. Memory should > also get updated in 1. as well. > > Brad, from your comment it seems that you expect that there can be > multiple read-write copies simultaneously. Is this possible, or would > this be a bug in the protocol? > > Brad Beckmann wrote: > You are absolutely right, that would be an error in the protocol. It > just seems that since we are scanning the state of the address in the system, > we might as well double check that at most one ReadWrite copy exists. > > I completely agree with your first two cases. However, I think the third > case is slightly too restrictive. Just because one memory has the address as > Busy, doesn't necessarily mean that we cannot update the block. If another > memory has the block in read-write state, we can be certain that that > particular copy is not only still valid, but has also yet to relinquish > exclusive ownership. Therefore a function write to that block can succeed. > Meanwhile, if we find a Busy block and just Read_Only block(s), than other > valid copies may exist somewhere in the system and thus the functional write > likely won't succeed. > > I'm confused by your fourth case. Isn't Ruby memory (a.k.a. > DirectoryMemory) just another AbstractMemory object and thus just another > memory in the list of memories? My hope was that we would treat CacheMemory > and DirectoryMemory the same when doing functional accesses. Am I missing > something? Brad, put it down to my lack of understanding of how the memory has been organized. Currently, it seems to me that directory memory will either have a sparse memory vector or a memory vector. These will contain the directory entries. It is these directory entries which hold the data blocks, which would be handled in a fashion similar to cache entries. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/#review1054 --- 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
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-31 20:44:17.499794) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - configs/ruby/MESI_CMP_directory.py c7302d55d644 configs/ruby/Ruby.py c7302d55d644 src/mem/ruby/network/Network.cc c7302d55d644 src/mem/ruby/network/Network.py c7302d55d644 src/mem/ruby/profiler/Profiler.cc c7302d55d644 src/mem/ruby/profiler/Profiler.py c7302d55d644 src/mem/ruby/recorder/Tracer.cc c7302d55d644 src/mem/ruby/recorder/Tracer.py c7302d55d644 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py c7302d55d644 src/mem/ruby/system/CacheMemory.hh c7302d55d644 src/mem/ruby/system/CacheMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.hh c7302d55d644 src/mem/ruby/system/DirectoryMemory.cc c7302d55d644 src/mem/ruby/system/DirectoryMemory.py c7302d55d644 src/mem/ruby/system/RubyPort.hh c7302d55d644 src/mem/ruby/system/RubyPort.cc c7302d55d644 src/mem/ruby/system/RubySystem.py c7302d55d644 src/mem/ruby/system/SConscript c7302d55d644 src/mem/ruby/system/Sequencer.cc c7302d55d644 src/mem/ruby/system/Sequencer.py c7302d55d644 src/mem/ruby/system/System.hh c7302d55d644 src/mem/ruby/system/System.cc c7302d55d644 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: CacheMemory: add allocateVoid() that is == allo...
Lisa, should not compiler yell in this case as well? Nilay On Thu, March 31, 2011 8:22 pm, Lisa Hsu wrote: > changeset c7302d55d644 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=c7302d55d644 > description: > CacheMemory: add allocateVoid() that is == allocate() but no return > value. > This function duplicates the functionality of allocate() exactly, except > that it does not return > a return value. In protocols where you just want to allocate a block > but do not want that block to be your implicitly passed cache_entry, use > this function. > Otherwise, SLICC will complain if you do not consume the pointer > returned > by allocate(), > and if you do a dummy assignment Entry foo := cache.allocate(address), > the C++ > compiler will complain of an unused variable. This is kind of a hack to > get around > those issues, but suggestions welcome. > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
> On 2011-03-31 14:22:16, Nilay Vaish wrote: > > I hope you have tested the existing protocols with these changes. > > Lisa Hsu wrote: > Yes - MOESI_[CMP_[directory|token]|hammer] all compile and run -l 1000 -n > 4 on the Ruby Tester. Since no logic has changed (for all my Ruby changes), > I believe it's sufficient testing, since the MSB in correctness is > compilation. That should be sufficient. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/624/#review1065 --- On 2011-03-31 12:20:53, Lisa Hsu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/624/ > --- > > (Updated 2011-03-31 12:20:53) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > Ruby: enable multiple sequencers in one controller. > > > Diffs > - > > src/mem/slicc/symbols/StateMachine.py d8587c913ccf > > Diff: http://reviews.m5sim.org/r/624/diff > > > Testing > --- > > > Thanks, > > Lisa > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
> 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: Simplify SLICC and Entry/TBE handling.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/630/#review1066
---
Ship it!
Lisa, the changes look fine to me. Just make sure that all the existing
protocols compile properly.
- Nilay
On 2011-03-31 14:26:33, Lisa Hsu wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/630/
> ---
>
> (Updated 2011-03-31 14:26:33)
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
>
>
> Summary
> ---
>
> Ruby: Simplify SLICC and Entry/TBE handling.
> Before this changeset, all local variables of type Entry and TBE were
> considered
> to be pointers, but an immediate use of said variables would not be
> automatically
> deferenced in SLICC-generated code. Instead, deferences occurred when such
> variables were passed to functions, and were automatically dereferenced in
> the bodies of the functions (e.g. the implicitly passed cache_entry).
>
> This is a more general way to do it, which leaves in place the
> assumption that parameters to functions and local variables of type
> AbstractCacheEntry
> and TBE are always pointers, but instead of dereferencing to access member
> variables
> on a contextual basis, the dereferencing automatically occurs on a type basis
> at the
> moment a member is being accessed. So, now, things you can do that you
> couldn't before
> include:
>
> Entry foo := getCacheEntry(address);
> cache_entry.DataBlk := foo.DataBlk;
>
> or
>
> cache_entry.DataBlk := getCacheEntry(address).DataBlk;
>
> or even
>
> cache_entry.DataBlk := static_cast(Entry, pointer,
> cache.lookup(address)).DataBlk;
>
>
> Diffs
> -
>
> src/mem/slicc/ast/ActionDeclAST.py d8587c913ccf
> src/mem/slicc/ast/FormalParamAST.py d8587c913ccf
> src/mem/slicc/ast/FuncCallExprAST.py d8587c913ccf
> src/mem/slicc/ast/IsValidPtrExprAST.py d8587c913ccf
> src/mem/slicc/ast/MemberExprAST.py d8587c913ccf
>
> Diff: http://reviews.m5sim.org/r/630/diff
>
>
> Testing
> ---
>
> So - just to add a note (this is not about testing). I had uploaded a patch,
> then realized that there was some dead code that I should also remove, so I
> uploaded a new patch. However, the head of my tree had changed, and that
> appears to have messed up my ability to update patches. So, two upshots:
>
> One, this newer patch gets rid of the some of the str.replace("*", "") code
> that was in place to auto-remove the *s from m_cache_entry and m_tbe, since
> now, those guys do not have *s by default.
>
> Two, don't change the head of your tree and have outstanding patches at the
> same time, if you think you want to update patches.
>
>
> Thanks,
>
> Lisa
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: enable multiple sequencers in one controller.
--- 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: have the rubytester pass contextId to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/625/#review1064 --- Ship it! - Nilay On 2011-03-31 12:20:59, Lisa Hsu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/625/ > --- > > (Updated 2011-03-31 12:20:59) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > Ruby: have the rubytester pass contextId to Ruby. > > > Diffs > - > > src/cpu/testers/rubytest/Check.cc d8587c913ccf > > Diff: http://reviews.m5sim.org/r/625/diff > > > Testing > --- > > > Thanks, > > Lisa > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add new object called WireBuffer to mimic a Wire.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/627/#review1063 --- src/mem/ruby/system/WireBuffer.hh <http://reviews.m5sim.org/r/627/#comment1430> Remove the comment. src/mem/ruby/system/WireBuffer.hh <http://reviews.m5sim.org/r/627/#comment1431> Remove this line as well. src/mem/ruby/system/WireBuffer.py <http://reviews.m5sim.org/r/627/#comment1429> Do we need this commented piece of code? - Nilay On 2011-03-31 12:21:07, Lisa Hsu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/627/ > --- > > (Updated 2011-03-31 12:21:07) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > Ruby: Add new object called WireBuffer to mimic a Wire. > This is a substitute for MessageBuffers between controllers where you don't > want messages to actually go through the Network, because requests/responses > can > always get reordered wrt to one another (even if you turn off Randomization > and turn on Ordered) > because you are, after all, going through a network with contention. For > systems where you model > multiple controllers that are very tightly coupled and do not actually go > through a network, > it is a pain to have to write a coherence protocol to account for mixed up > request/response orderings > despite the fact that it's completely unrealistic. This is *not* meant as a > substitute for real > MessageBuffers when messages do in fact go over a network. > > > Diffs > - > > src/mem/protocol/RubySlicc_Types.sm d8587c913ccf > src/mem/ruby/SConscript d8587c913ccf > src/mem/ruby/system/SConscript d8587c913ccf > src/mem/ruby/system/WireBuffer.hh PRE-CREATION > src/mem/ruby/system/WireBuffer.cc PRE-CREATION > src/mem/ruby/system/WireBuffer.py PRE-CREATION > src/mem/slicc/symbols/StateMachine.py d8587c913ccf > > Diff: http://reviews.m5sim.org/r/627/diff > > > Testing > --- > > > Thanks, > > Lisa > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CacheMemory: add allocateVoid() that is == allocate() but no return value.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/629/#review1062 --- Ship it! - Nilay On 2011-03-31 12:21:22, Lisa Hsu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/629/ > --- > > (Updated 2011-03-31 12:21:22) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > CacheMemory: add allocateVoid() that is == allocate() but no return value. > This function duplicates the functionality of allocate() exactly, except that > it does not return > a return value. In protocols where you just want to allocate a block > but do not want that block to be your implicitly passed cache_entry, use this > function. > Otherwise, SLICC will complain if you do not consume the pointer returned by > allocate(), > and if you do a dummy assignment Entry foo := cache.allocate(address), the C++ > compiler will complain of an unused variable. This is kind of a hack to get > around > those issues, but suggestions welcome. > > > Diffs > - > > src/mem/protocol/RubySlicc_Types.sm d8587c913ccf > src/mem/ruby/system/CacheMemory.hh d8587c913ccf > src/mem/ruby/system/CacheMemory.cc d8587c913ccf > > Diff: http://reviews.m5sim.org/r/629/diff > > > Testing > --- > > > Thanks, > > Lisa > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: pass Packet->Req->contextId() to Ruby.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/623/#review1060 --- Ship it! Is context Id being used any where? - Nilay On 2011-03-31 12:16:27, Lisa Hsu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/623/ > --- > > (Updated 2011-03-31 12:16:27) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > --- > > Ruby: pass Packet->Req->contextId() to Ruby. > It is useful for Ruby to understand from whence request packets came. > This has all request packets going into Ruby pass the contextId value, if > it exists. This supplants the old libruby proc_id value passed around in > all the Messages, so I've also removed the unused unsigned proc_id; member > generated by SLICC for all Message types. > > > Diffs > - > > src/mem/protocol/RubySlicc_Types.sm d8587c913ccf > src/mem/ruby/slicc_interface/RubyRequest.hh d8587c913ccf > src/mem/ruby/system/Sequencer.cc d8587c913ccf > src/mem/slicc/symbols/Type.py d8587c913ccf > > Diff: http://reviews.m5sim.org/r/623/diff > > > Testing > --- > > > Thanks, > > Lisa > > ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Ruby: Protocol.hh
I am wondering what's the need of the file Protocol.hh, I removed it from different in the protocol independent part of Ruby. I also removed the file standard_1level_CMP-protocol.sm from the MOESI_hammer.slicc. Everything compiles perfectly. I am not sure what the requirement is. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby Optimization Opportunity?
Korey, I do not have the FftBase32 benchmark. Is it possible for you to run the simulation with one of the following benchmarks -- IScsiInitiator, IScsiTarget, MutexTest, NetperfMaerts, NetperfStream, NetperfStreamNT, NetperfStreamUdp, NetperfUdpLocal, Nfs, NfsTcp, Nhfsstone, Ping, PovrayAutumn, PovrayBench, SurgeSpecweb, SurgeStandard, ValAccDelay, ValAccDelay2, ValCtxLat, ValMemLat, ValMemLat2MB, ValMemLat8MB, ValStream, ValStreamCopy, ValStreamScale, ValSysLat, ValTlbLat, Validation, bnAn Which of these do you think would closely resemble FFT? Nilay On Wed, 30 Mar 2011, Korey Sewell wrote: Hi all, I had noticed that Ruby was running a little slower than the old M5 memory system and decided to run gprof on it to see if there was anything obvious holding things up. For 2, 4, and 8 core ALPHA_FS_MOESI_CMP_directory, SimpleCPU runs for the Fft benchmark, it seems that the MemoryControl::executeCycle conributes to nearly 30% of the runtime. Looking at the comments for that code, I see this: "// executeCycle: This function is called once per memory clock cycle" I'm not familiar with this Memory Controller code but it would seem that some type of optimization not requiring this to be run every memory cycle would speed things up a good bit. So if someone has the time or the need to do some Ruby optimization work (i know Nilay had did some previously), then I think this will be a good place to start... I post some of the gprof output below: = 2 core = time (%) name 29.17 MemoryControl::executeCycle() 4.19RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.52PerfectSwitch::wakeup() 3.47Set::Set(Set const&) 3.46RubyEventQueueNode::process() 4 core = time (%) name 27.49MemoryControl::executeCycle() 4.01RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.66PerfectSwitch::wakeup() 3.59 Set::Set(Set const&) 3.50RubyEventQueueNode::process() 8 core = time (%) name 26.09MemoryControl::executeCycle() 4.12 Set::Set(Set const&) 3.91 PerfectSwitch::wakeup() 3.88 RubyEventQueue::scheduleEventAbsolute(Consumer*, long long) 3.41 RubyEventQueueNode::process() -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
On Tue, 29 Mar 2011, Nilay Vaish wrote: Brad, I have posted on the review board my current implementation for supporting functional accesses in Ruby. This is untested and is mainly meant for furthering the discussions. I have some questions for you -- 1. How do we inform the other end of RubyPort's M5 Port about whether or not functional access was successful? 2. What's the role of directory memory in functional accesses? 3. If none of the caches have the block pertaining to the address of the access, then read accesses should be satisfied from the physical memory. Write accesses should always go to physical memory as well. How can physical memory be accessed from RubyPort? -- Nilay Brad, I have made some changes to the patch. I have updated it on the review board. I have added a call to sendFunctional() so as to send the response. I have also added call to sendFunctional() on the physical memory port of ruby port, so that the physical memory would also get updated. You had mentioned that we would unhook M5 memory and use Ruby to supply the data. How do we do this? And the second question from the previous mail still remains unanswered. Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- (Updated 2011-03-30 16:19:26.551926) Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs (updated) - configs/ruby/MESI_CMP_directory.py d54b7775a6b0 configs/ruby/Ruby.py d54b7775a6b0 src/mem/ruby/network/Network.cc d54b7775a6b0 src/mem/ruby/network/Network.py d54b7775a6b0 src/mem/ruby/profiler/Profiler.cc d54b7775a6b0 src/mem/ruby/profiler/Profiler.py d54b7775a6b0 src/mem/ruby/recorder/Tracer.cc d54b7775a6b0 src/mem/ruby/recorder/Tracer.py d54b7775a6b0 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py d54b7775a6b0 src/mem/ruby/system/CacheMemory.hh d54b7775a6b0 src/mem/ruby/system/CacheMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.hh d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.cc d54b7775a6b0 src/mem/ruby/system/DirectoryMemory.py d54b7775a6b0 src/mem/ruby/system/RubyPort.hh d54b7775a6b0 src/mem/ruby/system/RubyPort.cc d54b7775a6b0 src/mem/ruby/system/RubySystem.py d54b7775a6b0 src/mem/ruby/system/SConscript d54b7775a6b0 src/mem/ruby/system/Sequencer.py d54b7775a6b0 src/mem/ruby/system/System.hh d54b7775a6b0 src/mem/ruby/system/System.cc d54b7775a6b0 Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Add support for functional accesses
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] Review Request: Ruby: Add support for functional accesses
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/611/ --- Review request for Default. Summary --- Ruby: Add support for functional accesses This patch is meant for aiding discussions on implementation of functional access support in Ruby. Diffs - configs/ruby/MESI_CMP_directory.py 6ae58f06a41c configs/ruby/Ruby.py 6ae58f06a41c src/mem/ruby/network/Network.cc 6ae58f06a41c src/mem/ruby/network/Network.py 6ae58f06a41c src/mem/ruby/profiler/Profiler.cc 6ae58f06a41c src/mem/ruby/profiler/Profiler.py 6ae58f06a41c src/mem/ruby/recorder/Tracer.cc 6ae58f06a41c src/mem/ruby/recorder/Tracer.py 6ae58f06a41c src/mem/ruby/system/AbstractMemory.hh PRE-CREATION src/mem/ruby/system/AbstractMemory.cc PRE-CREATION src/mem/ruby/system/Cache.py 6ae58f06a41c src/mem/ruby/system/CacheMemory.hh 6ae58f06a41c src/mem/ruby/system/CacheMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.hh 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.cc 6ae58f06a41c src/mem/ruby/system/DirectoryMemory.py 6ae58f06a41c src/mem/ruby/system/RubyPort.hh 6ae58f06a41c src/mem/ruby/system/RubyPort.cc 6ae58f06a41c src/mem/ruby/system/RubySystem.py 6ae58f06a41c src/mem/ruby/system/SConscript 6ae58f06a41c src/mem/ruby/system/Sequencer.py 6ae58f06a41c src/mem/ruby/system/System.hh 6ae58f06a41c src/mem/ruby/system/System.cc 6ae58f06a41c Diff: http://reviews.m5sim.org/r/611/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron /z/m5/regression/do-regression quick
I pushed in patch that imports math in MI_example.py -- Nilay On Mon, 28 Mar 2011, Cron Daemon wrote: * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby FAILED! * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby FAILED! * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby FAILED! * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby FAILED! * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby FAILED! ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Config: Import math in MI_example.py
changeset 1333bd6cc2eb in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=1333bd6cc2eb description: Config: Import math in MI_example.py diffstat: configs/ruby/MI_example.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (11 lines): diff -r 832ae3727c2b -r 1333bd6cc2eb configs/ruby/MI_example.py --- a/configs/ruby/MI_example.pySat Mar 26 22:24:36 2011 -0700 +++ b/configs/ruby/MI_example.pyMon Mar 28 10:49:36 2011 -0500 @@ -27,6 +27,7 @@ # # Authors: Brad Beckmann +import math import m5 from m5.objects import * from m5.defines import buildEnv ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby random tester failing with MESI_CMP_directory?
It is working fine for me. ./build/X86_SE_MESI_CMP_directory/m5.fast ./configs/example/ruby_random_test.py -n 4 -l 1 M5 Simulator System Copyright (c) 2001-2008 The Regents of The University of Michigan All Rights Reserved M5 compiled Mar 23 2011 15:53:38 M5 started Mar 23 2011 15:53:52 M5 executing on mumble-09.cs.wisc.edu command line: ./build/X86_SE_MESI_CMP_directory/m5.fast ./configs/example/ruby_random_test.py -n 4 -l 1 Global frequency set at 10 ticks per second info: Entering event queue @ 0. Starting simulation... hack: be nice to actually delete the event here Exiting @ tick 14536941 because Ruby Tester completed On Wed, 23 Mar 2011, Nilay Vaish wrote: I will try to bisect this. -- Nilay On Wed, 23 Mar 2011, Arkaprava Basu wrote: Hi Lisa and Nilay, Thanks for the response. Following is the tip of my repo changeset: 8174:e21f6e70169e tag: tip user:Nilay Vaish 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?
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 Vaish 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 FS - DMA Controller problem?
On Sat, March 19, 2011 6:01 pm, Beckmann, Brad wrote: > Korey, if you're deadlock is with running the MOESI_CMP_directory > protocol, I'm not surprised. DMA support is pretty much broken in that > protocol. I have that fixed and I also fixed the underlining DMA problem. > I'll be pushing the fixes momentarily. > > Korey and Malek, please pull these changes and confirm they fix your > problem. > > Brad > > Brad, how come the mails you sent on Saturday are being received now? -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Convert AccessModeType to RubyAccessMode
On Sat, March 19, 2011 3:57 pm, Beckmann, Brad wrote: > Nevermind, I understand the reason now. This looks good to me. > > Thanks, > > Brad > >> -Original Message- >> From: Beckmann, Brad >> Sent: Saturday, March 19, 2011 1:50 PM >> To: 'M5 Developer List' >> Subject: RE: [m5-dev] Review Request: Ruby: Convert AccessModeType to >> RubyAccessMode >> >> Hi Nilay, >> >> Why do you want to change the name? Both names seem equivalent to me. >> >> Brad >> >> Brad, I had to make the decision in favor of one of the two names. I decided not to choose AccessModeType because Mode and Type have almost the same meaning. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] networktest.cc error
On Tue, March 22, 2011 9:45 pm, Tushar Krishna wrote: > Hi all, > I didn't (and still don't) see any errors in networktest.cc when I built > m5 on my own computer for both SE and FS modes before checking in the > patch. > Could it be a gcc version issue? > > The error which the regression tester points to is > > build/ARM_FS/cpu/testers/networktest/networktest.cc:194: error: call > of overloaded 'pow(int, int&)' is ambiguous > > The line which is giving the error is: > int injRange = pow(10, precision); > > precision is an input parameter. > > I just want to raise 10 to an input integer value. Is there any other > way I should use to do this? > > What is the regression test that I should run to reproduce the errors > and warnings? > > Thanks, > Tushar > Tushar, try compiling with GCC 4.2, that's the version on zizzer. -- Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
