Re: [m5-dev] Review Request: Mem: Fix issue with dirty block being losted when entire block transfered to non-cache.

2011-02-25 Thread Steve Reinhardt 

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

Ship it!


Looks good to me, other than the minor non-substantive change to the 
assertions, and maybe some editing of the commit message ("losted"?  also 
"propagate" is spelled wrong)


src/cpu/o3/fetch_impl.hh


This is minor, but I'd prefer to see these two asserts written as:

!(pkt->memInhibitAsserted() && !pkt->sharedAsserted())

because this explicitly asserts that we're not seeing the combination of 
signals that indicates ownership, as opposed to having to apply De Morgan in 
your head to figure that out :-)



- Steve


On 2011-02-25 21:04:34, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/509/
> ---
> 
> (Updated 2011-02-25 21:04:34)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> Mem: Fix issue with dirty block being losted when entire block transfered to 
> non-cache.
> 
> This change fixes the problem for all the cases we actively use. If you want 
> to try
> more creative I/O device attachments (E.g. sharing an L2), this won't work. 
> You
> would need another level of caching between the I/O device and the cache
> (which you actually need anyway with our current code to make sure writes
> propigate). This is required so that you can mark the cache inbetween as
> top level and it won't try to send ownership of a block to the I/O device.
> Asserts have been added that should catch any issues.
> 
> 
> Diffs
> -
> 
>   configs/common/Caches.py 9dc17725f795 
>   src/cpu/o3/fetch_impl.hh 9dc17725f795 
>   src/dev/io_device.cc 9dc17725f795 
>   src/mem/cache/BaseCache.py 9dc17725f795 
>   src/mem/cache/base.hh 9dc17725f795 
>   src/mem/cache/base.cc 9dc17725f795 
>   src/mem/cache/cache_impl.hh 9dc17725f795 
>   tests/configs/inorder-timing.py 9dc17725f795 
>   tests/configs/memtest.py 9dc17725f795 
>   tests/configs/o3-timing-mp.py 9dc17725f795 
>   tests/configs/o3-timing.py 9dc17725f795 
>   tests/configs/pc-simple-atomic.py 9dc17725f795 
>   tests/configs/pc-simple-timing.py 9dc17725f795 
>   tests/configs/realview-simple-atomic.py 9dc17725f795 
>   tests/configs/realview-simple-timing.py 9dc17725f795 
>   tests/configs/simple-atomic-mp.py 9dc17725f795 
>   tests/configs/simple-timing-mp.py 9dc17725f795 
>   tests/configs/simple-timing.py 9dc17725f795 
>   tests/configs/tsunami-o3-dual.py 9dc17725f795 
>   tests/configs/tsunami-o3.py 9dc17725f795 
>   tests/configs/tsunami-simple-atomic-dual.py 9dc17725f795 
>   tests/configs/tsunami-simple-atomic.py 9dc17725f795 
>   tests/configs/tsunami-simple-timing-dual.py 9dc17725f795 
>   tests/configs/tsunami-simple-timing.py 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/509/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: ARM: Detect and skip udelay() functions in linux kernel.

2011-02-25 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

ARM: Detect and skip udelay() functions in linux kernel.

This change speeds up booting, especially in MP cases, by not executing
udelay() on the core but instead skipping ahead tha amount of time that is being
delayed.


Diffs
-

  src/arch/arm/linux/system.hh 9dc17725f795 
  src/arch/arm/linux/system.cc 9dc17725f795 
  src/kern/linux/events.hh 9dc17725f795 
  src/kern/linux/events.cc 9dc17725f795 

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


Testing
---


Thanks,

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: O3: Send instruction back to fetch on squash to seed predecoder correctly.

2011-02-25 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Send instruction back to fetch on squash to seed predecoder correctly.


Diffs
-

  src/arch/alpha/predecoder.hh 9dc17725f795 
  src/arch/arm/predecoder.hh 9dc17725f795 
  src/arch/mips/predecoder.hh 9dc17725f795 
  src/arch/power/predecoder.hh 9dc17725f795 
  src/arch/sparc/predecoder.hh 9dc17725f795 
  src/arch/x86/predecoder.hh 9dc17725f795 
  src/cpu/o3/cpu.cc 9dc17725f795 
  src/cpu/o3/fetch.hh 9dc17725f795 
  src/cpu/o3/fetch_impl.hh 9dc17725f795 

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


Testing
---


Thanks,

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: O3: Cleanup the commitInfo comm struct.

2011-02-25 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Cleanup the commitInfo comm struct.

Get rid of unused members and use base types rather than derrived values
where possible to limit amount of state. This cleans up a change to the
fetch stage I promised Steve a month ago.


Diffs
-

  src/cpu/o3/comm.hh 9dc17725f795 
  src/cpu/o3/commit.hh 9dc17725f795 
  src/cpu/o3/commit_impl.hh 9dc17725f795 
  src/cpu/o3/fetch_impl.hh 9dc17725f795 
  src/cpu/o3/iew_impl.hh 9dc17725f795 

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


Testing
---


Thanks,

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Mem: Fix issue with dirty block being losted when entire block transfered to non-cache.

2011-02-25 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

Mem: Fix issue with dirty block being losted when entire block transfered to 
non-cache.

This change fixes the problem for all the cases we actively use. If you want to 
try
more creative I/O device attachments (E.g. sharing an L2), this won't work. You
would need another level of caching between the I/O device and the cache
(which you actually need anyway with our current code to make sure writes
propigate). This is required so that you can mark the cache inbetween as
top level and it won't try to send ownership of a block to the I/O device.
Asserts have been added that should catch any issues.


Diffs
-

  configs/common/Caches.py 9dc17725f795 
  src/cpu/o3/fetch_impl.hh 9dc17725f795 
  src/dev/io_device.cc 9dc17725f795 
  src/mem/cache/BaseCache.py 9dc17725f795 
  src/mem/cache/base.hh 9dc17725f795 
  src/mem/cache/base.cc 9dc17725f795 
  src/mem/cache/cache_impl.hh 9dc17725f795 
  tests/configs/inorder-timing.py 9dc17725f795 
  tests/configs/memtest.py 9dc17725f795 
  tests/configs/o3-timing-mp.py 9dc17725f795 
  tests/configs/o3-timing.py 9dc17725f795 
  tests/configs/pc-simple-atomic.py 9dc17725f795 
  tests/configs/pc-simple-timing.py 9dc17725f795 
  tests/configs/realview-simple-atomic.py 9dc17725f795 
  tests/configs/realview-simple-timing.py 9dc17725f795 
  tests/configs/simple-atomic-mp.py 9dc17725f795 
  tests/configs/simple-timing-mp.py 9dc17725f795 
  tests/configs/simple-timing.py 9dc17725f795 
  tests/configs/tsunami-o3-dual.py 9dc17725f795 
  tests/configs/tsunami-o3.py 9dc17725f795 
  tests/configs/tsunami-simple-atomic-dual.py 9dc17725f795 
  tests/configs/tsunami-simple-atomic.py 9dc17725f795 
  tests/configs/tsunami-simple-timing-dual.py 9dc17725f795 
  tests/configs/tsunami-simple-timing.py 9dc17725f795 

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


Testing
---


Thanks,

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: O3: Fix unaligned stores when cache blocked

2011-02-25 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Fix unaligned stores when cache blocked

Without this change the a store can be issued to the cache multiple times.
If this case occurs when the l1 cache is out of mshrs (and thus blocked)
the processor will never make forward progress because each cycle it will
send a single request using the recently freed mshr and not complete the
multipart store. This will continue forever.


Diffs
-

  src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 

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


Testing
---


Thanks,

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: Ruby: Remove store buffer

2011-02-25 Thread Nilay Vaish 
changeset 05a2f6ac1f8e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=05a2f6ac1f8e
description:
Ruby: Remove store buffer
This patch removes the store buffer from Ruby. It is not in use 
currently.
Since libruby is being and store buffer makes calls to libruby, it is 
not
possible to maintain it until substantial changes are made.

diffstat:

 src/mem/ruby/storebuffer/SConscript   |   37 ---
 src/mem/ruby/storebuffer/stb_interface.cc |   85 
 src/mem/ruby/storebuffer/stb_interface.hh |   38 ---
 src/mem/ruby/storebuffer/storebuffer.cc   |  299 --
 src/mem/ruby/storebuffer/storebuffer.hh   |  151 ---
 5 files changed, 0 insertions(+), 610 deletions(-)

diffs (truncated from 630 to 300 lines):

diff -r 6782b51ae8a8 -r 05a2f6ac1f8e src/mem/ruby/storebuffer/SConscript
--- a/src/mem/ruby/storebuffer/SConscript   Fri Feb 25 17:54:56 2011 -0600
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,37 +0,0 @@
-# -*- mode:python -*-
-
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# All rights reserved.
-#
-# Redistribution and use in source and binary forms, with or without
-# modification, are permitted provided that the following conditions are
-# met: redistributions of source code must retain the above copyright
-# notice, this list of conditions and the following disclaimer;
-# redistributions in binary form must reproduce the above copyright
-# notice, this list of conditions and the following disclaimer in the
-# documentation and/or other materials provided with the distribution;
-# neither the name of the copyright holders nor the names of its
-# contributors may be used to endorse or promote products derived from
-# this software without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-#
-# Authors: Nathan Binkert
-
-Import('*')
-
-if not env['RUBY']:
-Return()
-
-Source('stb_interface.cc')
-Source('storebuffer.cc')
diff -r 6782b51ae8a8 -r 05a2f6ac1f8e src/mem/ruby/storebuffer/stb_interface.cc
--- a/src/mem/ruby/storebuffer/stb_interface.cc Fri Feb 25 17:54:56 2011 -0600
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,85 +0,0 @@
-/*
- * Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met: redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer;
- * redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution;
- * neither the name of the copyright holders nor the names of its
- * contributors may be used to endorse or promote products derived from
- * this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include 
-
-#include "mem/ruby/storebuffer/stb_interface.hh"
-
-StoreBuffer *
-createNewSTB(uint32 id, uint32 block_bits, int storebuffer_size)
-{
-StoreBuffer *stb = new StoreBuffer(id, block_bits, storebuffer_size);
-return stb;
-}
-
-storebuffer_status_t
-handleStore(StoreBuffer *storebuffer, const RubyRequest &request)
-{
-assert(request.type == RubyRequestType_ST);
-if (storebuffer->storeBuffer

[m5-dev] changeset in m5: Ruby: Remove libruby

2011-02-25 Thread Nilay Vaish 
changeset 6782b51ae8a8 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6782b51ae8a8
description:
Ruby: Remove libruby
This patch removes libruby_internal.hh, libruby.hh and libruby.cc. It 
moves
the contents to libruby.hh to RubyRequest.hh and RubyRequest.cc files.

diffstat:

 src/mem/ruby/SConscript |3 +-
 src/mem/ruby/libruby.cc |  271 
 src/mem/ruby/libruby.hh |  180 --
 src/mem/ruby/libruby_internal.hh|   41 
 src/mem/ruby/profiler/Profiler.hh   |1 -
 src/mem/ruby/recorder/CacheRecorder.hh  |1 -
 src/mem/ruby/recorder/TraceRecord.hh|1 -
 src/mem/ruby/recorder/Tracer.hh |1 -
 src/mem/ruby/slicc_interface/RubyRequest.cc |  100 ++
 src/mem/ruby/slicc_interface/RubyRequest.hh |  101 ++
 src/mem/ruby/slicc_interface/SConscript |1 +
 src/mem/ruby/storebuffer/storebuffer.cc |   48 
 src/mem/ruby/storebuffer/storebuffer.hh |2 +-
 src/mem/ruby/system/RubyPort.hh |2 +-
 src/mem/ruby/system/Sequencer.cc|2 +-
 15 files changed, 206 insertions(+), 549 deletions(-)

diffs (truncated from 925 to 300 lines):

diff -r 04078b1214dd -r 6782b51ae8a8 src/mem/ruby/SConscript
--- a/src/mem/ruby/SConscript   Fri Feb 25 17:51:56 2011 -0600
+++ b/src/mem/ruby/SConscript   Fri Feb 25 17:54:56 2011 -0600
@@ -43,8 +43,6 @@
 if not env['RUBY']:
 Return()
 
-Source('libruby.cc')
-
 def do_embed_text(target, source, env):
 """convert a text file into a file that can be embedded in C
 using an #include statement, that defines a \"const char *\" pointing
@@ -95,6 +93,7 @@
 MakeInclude('slicc_interface/AbstractProtocol.hh')
 MakeInclude('slicc_interface/Message.hh')
 MakeInclude('slicc_interface/NetworkMessage.hh')
+MakeInclude('slicc_interface/RubyRequest.hh')
 
 # External types
 MakeInclude('buffers/MessageBuffer.hh')
diff -r 04078b1214dd -r 6782b51ae8a8 src/mem/ruby/libruby.cc
--- a/src/mem/ruby/libruby.cc   Fri Feb 25 17:51:56 2011 -0600
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,271 +0,0 @@
-/*
- * Copyright (c) 2009 Mark D. Hill and David A. Wood
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met: redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer;
- * redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution;
- * neither the name of the copyright holders nor the names of its
- * contributors may be used to endorse or promote products derived from
- * this software without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include 
-#include 
-
-#include "config/gems_root.hh"
-#include "mem/ruby/common/Address.hh"
-#include "mem/ruby/eventqueue/RubyEventQueue.hh"
-#include "mem/ruby/libruby_internal.hh"
-#include "mem/ruby/recorder/Tracer.hh"
-#include "mem/ruby/system/MemoryVector.hh"
-#include "mem/ruby/system/RubyPort.hh"
-#include "mem/ruby/system/System.hh"
-
-using namespace std;
-
-string
-RubyRequestType_to_string(const RubyRequestType& obj)
-{
-switch(obj) {
-  case RubyRequestType_IFETCH:
-return "IFETCH";
-  case RubyRequestType_LD:
-return "LD";
-  case RubyRequestType_ST:
-return "ST";
-  case RubyRequestType_Load_Linked:
-return "Load_Linked";
-  case RubyRequestType_Store_Conditional:
-return "Store_Conditional";
-  case RubyRequestType_RMW_Read:
-return "RMW_Read";
-  case RubyRequestType_RMW_Write:
-return "RMW_Write";
-  case RubyRequestType_Locked_RMW_Read:
-return "Locked_RMW_Read";
-  case RubyRequestType_Locked_RMW_Write:
-return "Locked_RMW_Write";
-  case RubyRequestType_NULL:
-  default:
-assert(0);
-return "";
-}
-}
-
-RubyReque

[m5-dev] changeset in m5: Ruby: Make Address.hh independent of RubySystem

2011-02-25 Thread Nilay Vaish 
changeset 04078b1214dd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=04078b1214dd
description:
Ruby: Make Address.hh independent of RubySystem
This patch changes Address.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depend on
RubySystem have been moved to Address.cc file.

diffstat:

 src/mem/ruby/common/Address.cc  |  70 +++
 src/mem/ruby/common/Address.hh  |  74 +---
 src/mem/ruby/filters/BlockBloomFilter.cc|   1 +
 src/mem/ruby/filters/BulkBloomFilter.cc |   1 +
 src/mem/ruby/filters/LSB_CountingBloomFilter.cc |   1 +
 src/mem/ruby/filters/MultiGrainBloomFilter.cc   |   1 +
 src/mem/ruby/filters/NonCountingBloomFilter.cc  |   1 +
 7 files changed, 80 insertions(+), 69 deletions(-)

diffs (239 lines):

diff -r 722a0d28ee83 -r 04078b1214dd src/mem/ruby/common/Address.cc
--- a/src/mem/ruby/common/Address.ccFri Feb 25 17:51:02 2011 -0600
+++ b/src/mem/ruby/common/Address.ccFri Feb 25 17:51:56 2011 -0600
@@ -27,6 +27,76 @@
  */
 
 #include "mem/ruby/common/Address.hh"
+#include "mem/ruby/system/System.hh"
+
+physical_address_t
+Address::getLineAddress() const
+{
+return bitSelect(RubySystem::getBlockSizeBits(), ADDRESS_WIDTH);
+}
+
+physical_address_t
+Address::getOffset() const
+{
+return bitSelect(0, RubySystem::getBlockSizeBits() - 1);
+}
+
+void
+Address::makeLineAddress()
+{
+m_address = maskLowOrderBits(RubySystem::getBlockSizeBits());
+}
+
+// returns the next stride address based on line address
+void
+Address::makeNextStrideAddress(int stride)
+{
+m_address = maskLowOrderBits(RubySystem::getBlockSizeBits())
++ RubySystem::getBlockSizeBytes()*stride;
+}
+
+integer_t
+Address::memoryModuleIndex() const
+{
+integer_t index =
+bitSelect(RubySystem::getBlockSizeBits() +
+  RubySystem::getMemorySizeBits(), ADDRESS_WIDTH);
+assert (index >= 0);
+return index;
+
+// Index indexHighPortion =
+// address.bitSelect(MEMORY_SIZE_BITS - 1,
+//   PAGE_SIZE_BITS + NUMBER_OF_MEMORY_MODULE_BITS);
+// Index indexLowPortion =
+// address.bitSelect(DATA_BLOCK_BITS, PAGE_SIZE_BITS - 1);
+//
+// Index index = indexLowPortion |
+// (indexHighPortion << (PAGE_SIZE_BITS - DATA_BLOCK_BITS));
+
+/*
+  Round-robin mapping of addresses, at page size granularity
+
+ADDRESS_WIDTHMEMORY_SIZE_BITSPAGE_SIZE_BITS  DATA_BLOCK_BITS
+  ||   |   |
+ \ /  \ / \ / \ /   0
+  ---
+  |   unused|xxx|   |xxx|   |
+  | |xxx|   |xxx|   |
+  ---
+indexHighPortion indexLowPortion
+<--->
+   NUMBER_OF_MEMORY_MODULE_BITS
+*/
+}
+
+void
+Address::print(std::ostream& out) const
+{
+using namespace std;
+out << "[" << hex << "0x" << m_address << "," << " line 0x"
+<< maskLowOrderBits(RubySystem::getBlockSizeBits()) << dec << "]"
+<< flush;
+}
 
 void
 Address::output(std::ostream& out) const
diff -r 722a0d28ee83 -r 04078b1214dd src/mem/ruby/common/Address.hh
--- a/src/mem/ruby/common/Address.hhFri Feb 25 17:51:02 2011 -0600
+++ b/src/mem/ruby/common/Address.hhFri Feb 25 17:51:56 2011 -0600
@@ -29,13 +29,13 @@
 #ifndef __MEM_RUBY_COMMON_ADDRESS_HH__
 #define __MEM_RUBY_COMMON_ADDRESS_HH__
 
+#include 
 #include 
 
 #include "base/hashmap.hh"
 #include "mem/ruby/common/Global.hh"
 #include "mem/ruby/system/MachineID.hh"
 #include "mem/ruby/system/NodeID.hh"
-#include "mem/ruby/system/System.hh"
 
 const int ADDRESS_WIDTH = 64; // address width in bytes
 
@@ -67,31 +67,10 @@
 physical_address_t maskHighOrderBits(int number) const;
 physical_address_t shiftLowOrderBits(int number) const;
 
-physical_address_t
-getLineAddress() const
-{
-return bitSelect(RubySystem::getBlockSizeBits(), ADDRESS_WIDTH);
-}
-
-physical_address_t
-getOffset() const
-{
-return bitSelect(0, RubySystem::getBlockSizeBits() - 1);
-}
-
-void
-makeLineAddress()
-{
-m_address = maskLowOrderBits(RubySystem::getBlockSizeBits());
-}
-
-// returns the next stride address based on line address
-void
-makeNextStrideAddress(int stride)
-{
-m_address = maskLowOrderBits(RubySystem::getBlockSizeBits())
-+ RubySystem::getBlockSizeBytes()*stride;
-}
+physical_address_t getLineAddress() const;
+physical_address_t getOffset() const;
+void makeLineAddress();
+

[m5-dev] changeset in m5: Ruby: Make DataBlock.hh independent of RubySystem

2011-02-25 Thread Nilay Vaish 
changeset 722a0d28ee83 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=722a0d28ee83
description:
Ruby: Make DataBlock.hh independent of RubySystem
This patch changes DataBlock.hh so that it is not dependent on 
RubySystem.
This dependence seems unecessary. All those functions that depende on
RubySystem have been moved to DataBlock.cc file.

diffstat:

 src/cpu/testers/rubytest/RubyTester.hh |   1 -
 src/mem/ruby/common/DataBlock.cc   |  56 ++
 src/mem/ruby/common/DataBlock.hh   |  56 +-
 3 files changed, 57 insertions(+), 56 deletions(-)

diffs (170 lines):

diff -r 4a59661d3fd1 -r 722a0d28ee83 src/cpu/testers/rubytest/RubyTester.hh
--- a/src/cpu/testers/rubytest/RubyTester.hhFri Feb 25 13:50:29 2011 +
+++ b/src/cpu/testers/rubytest/RubyTester.hhFri Feb 25 17:51:02 2011 -0600
@@ -37,7 +37,6 @@
 #include "cpu/testers/rubytest/CheckTable.hh"
 #include "mem/mem_object.hh"
 #include "mem/packet.hh"
-#include "mem/ruby/common/DataBlock.hh"
 #include "mem/ruby/common/Global.hh"
 #include "mem/ruby/common/SubBlock.hh"
 #include "mem/ruby/system/RubyPort.hh"
diff -r 4a59661d3fd1 -r 722a0d28ee83 src/mem/ruby/common/DataBlock.cc
--- a/src/mem/ruby/common/DataBlock.cc  Fri Feb 25 13:50:29 2011 +
+++ b/src/mem/ruby/common/DataBlock.cc  Fri Feb 25 17:51:02 2011 -0600
@@ -27,6 +27,62 @@
  */
 
 #include "mem/ruby/common/DataBlock.hh"
+#include "mem/ruby/system/System.hh"
+
+DataBlock::DataBlock(const DataBlock &cp)
+{
+m_data = new uint8[RubySystem::getBlockSizeBytes()];
+memcpy(m_data, cp.m_data, RubySystem::getBlockSizeBytes());
+m_alloc = true;
+}
+
+void
+DataBlock::alloc()
+{
+m_data = new uint8[RubySystem::getBlockSizeBytes()];
+m_alloc = true;
+clear();
+}
+
+void
+DataBlock::clear()
+{
+memset(m_data, 0, RubySystem::getBlockSizeBytes());
+}
+
+bool
+DataBlock::equal(const DataBlock& obj) const
+{
+return !memcmp(m_data, obj.m_data, RubySystem::getBlockSizeBytes());
+}
+
+void
+DataBlock::print(std::ostream& out) const
+{
+using namespace std;
+
+int size = RubySystem::getBlockSizeBytes();
+out << "[ ";
+for (int i = 0; i < size; i++) {
+out << setw(2) << setfill('0') << hex << "0x" << (int)m_data[i] << " ";
+out << setfill(' ');
+}
+out << dec << "]" << flush;
+}
+
+const uint8*
+DataBlock::getData(int offset, int len) const
+{
+assert(offset + len <= RubySystem::getBlockSizeBytes());
+return &m_data[offset];
+}
+
+void
+DataBlock::setData(uint8* data, int offset, int len)
+{
+assert(offset + len <= RubySystem::getBlockSizeBytes());
+memcpy(&m_data[offset], data, len);
+}
 
 DataBlock &
 DataBlock::operator=(const DataBlock & obj)
diff -r 4a59661d3fd1 -r 722a0d28ee83 src/mem/ruby/common/DataBlock.hh
--- a/src/mem/ruby/common/DataBlock.hh  Fri Feb 25 13:50:29 2011 +
+++ b/src/mem/ruby/common/DataBlock.hh  Fri Feb 25 17:51:02 2011 -0600
@@ -33,7 +33,6 @@
 #include 
 
 #include "mem/ruby/common/Global.hh"
-#include "mem/ruby/system/System.hh"
 
 class DataBlock
 {
@@ -43,12 +42,7 @@
 alloc();
 }
 
-DataBlock(const DataBlock &cp)
-{
-m_data = new uint8[RubySystem::getBlockSizeBytes()];
-memcpy(m_data, cp.m_data, RubySystem::getBlockSizeBytes());
-m_alloc = true;
-}
+DataBlock(const DataBlock &cp);
 
 ~DataBlock()
 {
@@ -85,53 +79,12 @@
 m_alloc = false;
 }
 
-inline void
-DataBlock::alloc()
-{
-m_data = new uint8[RubySystem::getBlockSizeBytes()];
-m_alloc = true;
-clear();
-}
-
-inline void
-DataBlock::clear()
-{
-memset(m_data, 0, RubySystem::getBlockSizeBytes());
-}
-
-inline bool
-DataBlock::equal(const DataBlock& obj) const
-{
-return !memcmp(m_data, obj.m_data, RubySystem::getBlockSizeBytes());
-}
-
-inline void
-DataBlock::print(std::ostream& out) const
-{
-using namespace std;
-
-int size = RubySystem::getBlockSizeBytes();
-out << "[ ";
-for (int i = 0; i < size; i++) {
-out << setw(2) << setfill('0') << hex << "0x" << (int)m_data[i] << " ";
-out << setfill(' ');
-}
-out << dec << "]" << flush;
-}
-
 inline uint8
 DataBlock::getByte(int whichByte) const
 {
 return m_data[whichByte];
 }
 
-inline const uint8*
-DataBlock::getData(int offset, int len) const
-{
-assert(offset + len <= RubySystem::getBlockSizeBytes());
-return &m_data[offset];
-}
-
 inline void
 DataBlock::setByte(int whichByte, uint8 data)
 {
@@ -139,13 +92,6 @@
 }
 
 inline void
-DataBlock::setData(uint8* data, int offset, int len)
-{
-assert(offset + len <= RubySystem::getBlockSizeBytes());
-memcpy(&m_data[offset], data, len);
-}
-
-inline void
 DataBlock::copyPartial(const DataBlock & dblk, int offset, int len)
 {
 setData(&dblk.m_data[offset], offset, len);
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listi

Re: [m5-dev] Store Buffer

2011-02-25 Thread Beckmann, Brad 
It sounds like we are in agreement here, but I just want to make sure we 
clarify one item.  I don't believe simply checking the coherence permissions at 
commit time can sufficiently support stronger consistency models like SC/TSO.  
Instead you need to really need to know whether you've ever lost the block 
since the speculative instruction read it.  Therefore, Ruby really does need to 
forward invalidations to the CPU.

It sounded like from your responses that you understand that as well, but I 
just wanted to make the point clear.

Brad


From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of 
Steve Reinhardt
Sent: Friday, February 25, 2011 10:29 AM
To: M5 Developer List
Subject: Re: [m5-dev] Store Buffer

This sounds right.  Ruby does need to forward invalidations to the CPU since 
some models (including O3) will need to do internal invalidations/flushes to 
maintain consistency.  Others can choose to do it other ways (e.g., by querying 
the L1 at commit as you suggest), but they have the option of ignoring the 
forwarded invalidations, so that's not a problem.

Steve
On Fri, Feb 25, 2011 at 9:07 AM, Arkaprava Basu 
mailto:aba...@wisc.edu>> wrote:
In sum, I think we all agree that Ruby is going to handle *only non-speculative 
stores*.  M5 CPU model(s) handles all of speculative and non-speculative stores 
that are *yet to be revealed to the memory sub-system*.

To make it clearer, as I understand,  we now have following:

1. All store buffering (speculative and non-speculative) is handled by CPU 
model in M5.
2. Ruby needs to forward intervention/invalidation received at L1 cache 
controller to the CPU model to let it take appropriate action to guarantee 
required memory consistency guarantees (e.g t may need to flush pipeline).
OR
CPU models need to check coherence permission at L1 cache at the commit 
time to know if intervening writes has happened or not (might be required to 
implement stricter model like SC).

I think we need to provide one of the functionality from Ruby side to allow the 
second condition above. Which one to provide depends upon what M5 CPU models 
wants to do to guarantee consistency.

Please let me know if you disagree or if I am missing something.

Thanks
Arka





On 02/24/2011 05:22 PM, Beckmann, Brad wrote:

So I think Steve and I are in agreement here.  We both agree that both 
speculative and non-speculative store buffers should be on the CPU side of the 
RubyPort interface.  I believe that was the same line that existed when Ruby 
tied to Opal in GEMS.  I believe the non-speculative store buffer was only a 
feature used when Opal was not attached, and it was just the simple 
SimicsProcessor driving Ruby.



The sequencer is a separate issue.  Certain functionality of the sequencer can 
probably be eliminated in gem5, but I think other functionality needs to remain 
or at least be moved to some other part of Ruby.  The sequencer performs a lot 
of protocol independent functionality including: updating the actual data 
block, performing synchronization with respect to the cache memory, translating 
m5 packets to ruby requests, checking for per-cacheblock deadlock, and 
coalescing requests to the same cache block.  The coalescing functionality can 
probably be eliminated, but I think the other functionality needs to remain.



Brad





From: m5-dev-boun...@m5sim.org 
[mailto:m5-dev-boun...@m5sim.org

] On Behalf Of Steve Reinhardt

Sent: Thursday, February 24, 2011 1:52 PM

To: M5 Developer List

Subject: Re: [m5-dev] Store Buffer





On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish 
mailto:ni...@cs.wisc.edu>>
 wrote:

On Thu, 24 Feb 2011, Beckmann, Brad wrote:

Steve, I think we are in agreement here and we may just be disagreeing with the 
definition of speculative.  From the Ruby perspective, I don't think it really 
matters...I don't think there is difference between a speculative store address 
request and a prefetch-with-write-intent. Also we agree that probes will need 
to be sent to O3 LSQ to support the consistency model.

My point is that if we believe this functionality is required, what is the 
extra overhead of adding a non-speculative store buffer to the O3 model as 
well?  I think that will be easier than trying to incorporate the current Ruby 
non-speculative store buffer into each protocol.



I don't know the O3 LSQ model very well, but I assume it buffers both 
speculative and non-speculative stores.  Are there two different structures in 
Ruby for that?



I think the general issue here is that the dividing line between "processor" 
and "memory system" is different in M5 than it was with GEMS. with M5 assuming 
that write buffers, redundant request filtering, etc. all happens in the 
"processor".  For example, I know I've had you explain this to me multiple 
times already, but I still don't understand why we still need R

Re: [m5-dev] Functional Access support in Ruby

2011-02-25 Thread Beckmann, Brad 
Yes, that is correct.  The RubyPort::M5Port::recvFunctional() function is where 
we need to add the new support.

Brad


> -Original Message-
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
> On Behalf Of Nilay Vaish
> Sent: Friday, February 25, 2011 12:20 PM
> To: m5-dev@m5sim.org
> Subject: [m5-dev] Functional Access support in Ruby
> 
> Brad,
> 
> Here is my understanding of the current state of functional accesses in gem5.
> As of now, all functional accesses are forwarded to the PhysicalMemory's
> MemoryPort. Instead, we would like to add
> recvFunctional() function to M5Port of the RubyPort, and attach this port as
> peer instead of the PhysicalMemory.
> 
> --
> 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

Re: [m5-dev] Review Request: Ruby: Make DataBlock.hh independent of RubySystem

2011-02-25 Thread Brad Beckmann 

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

Ship it!


- Brad


On 2011-02-25 10:51:51, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/503/
> ---
> 
> (Updated 2011-02-25 10:51:51)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Change DataBlock.hh
> This patch changes DataBlock.hh so that it is not dependent on RubySystem.
> This dependence seems unecessary. All those functions that depende on
> RubySystem have been moved to DataBlock.cc file.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
>   src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
>   src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/503/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: Make Address.hh independent of RubySystem

2011-02-25 Thread Brad Beckmann 

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

Ship it!


- Brad


On 2011-02-25 10:51:09, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/504/
> ---
> 
> (Updated 2011-02-25 10:51:09)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> Ruby: Change Address.hh
> This patch changes Address.hh so that it is not dependent on RubySystem.
> This dependence seems unecessary. All those functions that depend on
> RubySystem have been moved to Address.cc file.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/common/Address.hh UNKNOWN 
>   src/mem/ruby/common/Address.cc UNKNOWN 
>   src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
> 
> Diff: http://reviews.m5sim.org/r/504/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: Remove libruby

2011-02-25 Thread Brad Beckmann 

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

Ship it!


- Brad


On 2011-02-25 08:32:18, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/439/
> ---
> 
> (Updated 2011-02-25 08:32:18)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Remove libruby
> This patch removes libruby from Ruby. It is no longer required. The
> structures defined in this file have been moved to
> slicc_interface/RubyRequest.hh file.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/SConscript 4a59661d3fd1 
>   src/mem/ruby/libruby.hh 4a59661d3fd1 
>   src/mem/ruby/libruby.cc 4a59661d3fd1 
>   src/mem/ruby/profiler/Profiler.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 
>   src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
>   src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION 
>   src/mem/ruby/slicc_interface/SConscript 4a59661d3fd1 
>   src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
>   src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 
>   src/mem/ruby/system/RubyPort.hh 4a59661d3fd1 
>   src/mem/ruby/system/Sequencer.cc 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/439/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: Remove store buffer

2011-02-25 Thread Brad Beckmann 

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

Ship it!


- Brad


On 2011-02-25 08:33:43, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/507/
> ---
> 
> (Updated 2011-02-25 08:33:43)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Remove store buffer
> This patch removes the store buffer from Ruby. It is not in use currently.
> Since libruby is being and store buffer makes calls to libruby, it is not
> possible to maintain it until substantial changes are made.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/storebuffer/SConscript 4a59661d3fd1 
>   src/mem/ruby/storebuffer/stb_interface.hh 4a59661d3fd1 
>   src/mem/ruby/storebuffer/stb_interface.cc 4a59661d3fd1 
>   src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
>   src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/507/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Functional Access support in Ruby

2011-02-25 Thread Nilay Vaish 

Brad,

Here is my understanding of the current state of functional accesses in 
gem5. As of now, all functional accesses are forwarded to the 
PhysicalMemory's MemoryPort. Instead, we would like to add 
recvFunctional() function to M5Port of the RubyPort, and attach this port 
as peer instead of the PhysicalMemory.


--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Ruby: Remove libruby_internal.hh

2011-02-25 Thread Nilay Vaish 


> On 2011-02-25 09:43:34, Nathan Binkert wrote:
> > It seems that this diff should just be folded into the remove libruby diff.

I will do that before committing these to repository.


- Nilay


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


On 2011-02-25 08:30:30, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/506/
> ---
> 
> (Updated 2011-02-25 08:30:30)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Remove libruby_internal.hh
> This patch removes libruby_internal.hh and moves its contents to libruby.hh
> file.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/libruby.cc 4a59661d3fd1 
>   src/mem/ruby/libruby_internal.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/CacheRecorder.hh 4a59661d3fd1 
>   src/mem/ruby/libruby.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/TraceRecord.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/506/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: Make DataBlock.hh independent of RubySystem

2011-02-25 Thread Nilay Vaish 

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

(Updated 2011-02-25 10:51:51.189669)


Review request for Default.


Summary (updated)
---

Ruby: Change DataBlock.hh
This patch changes DataBlock.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depende on
RubySystem have been moved to DataBlock.cc file.


Diffs
-

  src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 

Diff: http://reviews.m5sim.org/r/503/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: Make Address.hh independent of RubySystem

2011-02-25 Thread Nilay Vaish 

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

(Updated 2011-02-25 10:51:09.206696)


Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary (updated)
---

Ruby: Change Address.hh
This patch changes Address.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depend on
RubySystem have been moved to Address.cc file.


Diffs
-

  src/mem/ruby/common/Address.hh UNKNOWN 
  src/mem/ruby/common/Address.cc UNKNOWN 
  src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Store Buffer

2011-02-25 Thread Steve Reinhardt 
This sounds right.  Ruby does need to forward invalidations to the CPU since
some models (including O3) will need to do internal invalidations/flushes to
maintain consistency.  Others can choose to do it other ways (e.g., by
querying the L1 at commit as you suggest), but they have the option of
ignoring the forwarded invalidations, so that's not a problem.

Steve

On Fri, Feb 25, 2011 at 9:07 AM, Arkaprava Basu  wrote:

>  In sum, I think we all agree that Ruby is going to handle *only
> non-speculative stores*.  M5 CPU model(s) handles all of speculative and
> non-speculative stores that are *yet to be revealed to the memory
> sub-system*.
>
> To make it clearer, as I understand,  we now have following:
>
> 1. All store buffering (speculative and non-speculative) is handled by CPU
> model in M5.
> 2. Ruby needs to forward intervention/invalidation received at L1 cache
> controller to the CPU model to let it take appropriate action to guarantee
> required memory consistency guarantees (e.g t may need to flush pipeline).
> OR
> CPU models need to check coherence permission at L1 cache at the commit
> time to know if intervening writes has happened or not (might be required to
> implement stricter model like SC).
>
> I think we need to provide one of the functionality from Ruby side to allow
> the second condition above. Which one to provide depends upon what M5 CPU
> models wants to do to guarantee consistency.
>
> Please let me know if you disagree or if I am missing something.
>
> Thanks
> Arka
>
>
>
>
>
> On 02/24/2011 05:22 PM, Beckmann, Brad wrote:
>
> So I think Steve and I are in agreement here.  We both agree that both 
> speculative and non-speculative store buffers should be on the CPU side of 
> the RubyPort interface.  I believe that was the same line that existed when 
> Ruby tied to Opal in GEMS.  I believe the non-speculative store buffer was 
> only a feature used when Opal was not attached, and it was just the simple 
> SimicsProcessor driving Ruby.
>
> The sequencer is a separate issue.  Certain functionality of the sequencer 
> can probably be eliminated in gem5, but I think other functionality needs to 
> remain or at least be moved to some other part of Ruby.  The sequencer 
> performs a lot of protocol independent functionality including: updating the 
> actual data block, performing synchronization with respect to the cache 
> memory, translating m5 packets to ruby requests, checking for per-cacheblock 
> deadlock, and coalescing requests to the same cache block.  The coalescing 
> functionality can probably be eliminated, but I think the other functionality 
> needs to remain.
>
> Brad
>
>
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org 
> 
> ] On Behalf Of Steve Reinhardt
> Sent: Thursday, February 24, 2011 1:52 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Store Buffer
>
>
> On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish 
> mailto:ni...@cs.wisc.edu> > wrote:
> On Thu, 24 Feb 2011, Beckmann, Brad wrote:
> Steve, I think we are in agreement here and we may just be disagreeing with 
> the definition of speculative.  From the Ruby perspective, I don't think it 
> really matters...I don't think there is difference between a speculative 
> store address request and a prefetch-with-write-intent. Also we agree that 
> probes will need to be sent to O3 LSQ to support the consistency model.
> My point is that if we believe this functionality is required, what is the 
> extra overhead of adding a non-speculative store buffer to the O3 model as 
> well?  I think that will be easier than trying to incorporate the current 
> Ruby non-speculative store buffer into each protocol.
>
> I don't know the O3 LSQ model very well, but I assume it buffers both 
> speculative and non-speculative stores.  Are there two different structures 
> in Ruby for that?
>
> I think the general issue here is that the dividing line between "processor" 
> and "memory system" is different in M5 than it was with GEMS. with M5 
> assuming that write buffers, redundant request filtering, etc. all happens in 
> the "processor".  For example, I know I've had you explain this to me 
> multiple times already, but I still don't understand why we still need Ruby 
> sequencers either :-).
>
> Brad, I raise the same point that Arka raised earlier. Other processor models 
> can also make use of store buffer. So, why only O3 should have a store buffer?
>
> Nilay, I think that's a different issue... we're not saying that other CPU 
> models can't have store buffers, but in practice, the simple CPU models block 
> on memory accesses so they don't need one.  If the inorder model wants to add 
> a store buffer (if it doesn't already have one), it would be an internal 
> decision for them whether they want to write one from scratch or try to reuse 
> the O3 code.  There are already some shared structures in src/cpu like branch 
> predictors that can be reused across CPU models.
>
> So in ot

Re: [m5-dev] Review Request: Ruby: Change DataBlock.hh

2011-02-25 Thread Nathan Binkert 

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


Please make the summary more descriptive.  For example:
ruby: Make DataBlock not depend on RubySystem

- Nathan


On 2011-02-25 08:34:04, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/503/
> ---
> 
> (Updated 2011-02-25 08:34:04)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Change DataBlock.hh
> This patch changes DataBlock.hh so that it is not dependent on RubySystem.
> This dependence seems unecessary. All those functions that depende on
> RubySystem have been moved to DataBlock.cc file.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
>   src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
>   src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/503/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: Remove libruby_internal.hh

2011-02-25 Thread Nathan Binkert 

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


It seems that this diff should just be folded into the remove libruby diff.

- Nathan


On 2011-02-25 08:30:30, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/506/
> ---
> 
> (Updated 2011-02-25 08:30:30)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Ruby: Remove libruby_internal.hh
> This patch removes libruby_internal.hh and moves its contents to libruby.hh
> file.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/libruby.cc 4a59661d3fd1 
>   src/mem/ruby/libruby_internal.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/CacheRecorder.hh 4a59661d3fd1 
>   src/mem/ruby/libruby.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/TraceRecord.hh 4a59661d3fd1 
>   src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 
> 
> Diff: http://reviews.m5sim.org/r/506/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: Change Address.hh

2011-02-25 Thread Nathan Binkert 

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


The summary line is a pretty non-descriptive summary

- Nathan


On 2011-02-25 08:28:07, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/504/
> ---
> 
> (Updated 2011-02-25 08:28:07)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> Ruby: Change Address.hh
> This patch changes Address.hh so that it is not dependent on RubySystem.
> This dependence seems unecessary. All those functions that depend on
> RubySystem have been moved to Address.cc file.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/common/Address.hh UNKNOWN 
>   src/mem/ruby/common/Address.cc UNKNOWN 
>   src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 
> 
> Diff: http://reviews.m5sim.org/r/504/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Store Buffer

2011-02-25 Thread Arkaprava Basu 
In sum, I think we all agree that Ruby is going to handle *only 
non-speculative stores*.  M5 CPU model(s) handles all of speculative and 
non-speculative stores that are *yet to be revealed to the memory 
sub-system*.


To make it clearer, as I understand,  we now have following:

1. All store buffering (speculative and non-speculative) is handled by 
CPU model in M5.
2. Ruby needs to forward intervention/invalidation received at L1 cache 
controller to the CPU model to let it take appropriate action to 
guarantee required memory consistency guarantees (e.g t may need to 
flush pipeline).

OR
CPU models need to check coherence permission at L1 cache at the 
commit time to know if intervening writes has happened or not (might be 
required to implement stricter model like SC).


I think we need to provide one of the functionality from Ruby side to 
allow the second condition above. Which one to provide depends upon what 
M5 CPU models wants to do to guarantee consistency.


Please let me know if you disagree or if I am missing something.

Thanks
Arka




On 02/24/2011 05:22 PM, Beckmann, Brad wrote:

So I think Steve and I are in agreement here.  We both agree that both 
speculative and non-speculative store buffers should be on the CPU side of the 
RubyPort interface.  I believe that was the same line that existed when Ruby 
tied to Opal in GEMS.  I believe the non-speculative store buffer was only a 
feature used when Opal was not attached, and it was just the simple 
SimicsProcessor driving Ruby.

The sequencer is a separate issue.  Certain functionality of the sequencer can 
probably be eliminated in gem5, but I think other functionality needs to remain 
or at least be moved to some other part of Ruby.  The sequencer performs a lot 
of protocol independent functionality including: updating the actual data 
block, performing synchronization with respect to the cache memory, translating 
m5 packets to ruby requests, checking for per-cacheblock deadlock, and 
coalescing requests to the same cache block.  The coalescing functionality can 
probably be eliminated, but I think the other functionality needs to remain.

Brad


From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of 
Steve Reinhardt
Sent: Thursday, February 24, 2011 1:52 PM
To: M5 Developer List
Subject: Re: [m5-dev] Store Buffer


On Thu, Feb 24, 2011 at 1:32 PM, Nilay 
Vaishmailto:ni...@cs.wisc.edu>>  wrote:
On Thu, 24 Feb 2011, Beckmann, Brad wrote:
Steve, I think we are in agreement here and we may just be disagreeing with the 
definition of speculative.  From the Ruby perspective, I don't think it really 
matters...I don't think there is difference between a speculative store address 
request and a prefetch-with-write-intent. Also we agree that probes will need 
to be sent to O3 LSQ to support the consistency model.
My point is that if we believe this functionality is required, what is the 
extra overhead of adding a non-speculative store buffer to the O3 model as 
well?  I think that will be easier than trying to incorporate the current Ruby 
non-speculative store buffer into each protocol.

I don't know the O3 LSQ model very well, but I assume it buffers both 
speculative and non-speculative stores.  Are there two different structures in 
Ruby for that?

I think the general issue here is that the dividing line between "processor" and "memory 
system" is different in M5 than it was with GEMS. with M5 assuming that write buffers, redundant request 
filtering, etc. all happens in the "processor".  For example, I know I've had you explain this to 
me multiple times already, but I still don't understand why we still need Ruby sequencers either :-).

Brad, I raise the same point that Arka raised earlier. Other processor models 
can also make use of store buffer. So, why only O3 should have a store buffer?

Nilay, I think that's a different issue... we're not saying that other CPU 
models can't have store buffers, but in practice, the simple CPU models block 
on memory accesses so they don't need one.  If the inorder model wants to add a 
store buffer (if it doesn't already have one), it would be an internal decision 
for them whether they want to write one from scratch or try to reuse the O3 
code.  There are already some shared structures in src/cpu like branch 
predictors that can be reused across CPU models.

So in other words we need to decide first where the store buffer should live 
(CPU or memory system) and then we can worry about how to reuse that code if 
that's useful.
Steve



___
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: Change DataBlock.hh

2011-02-25 Thread Nilay Vaish 

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

(Updated 2011-02-25 08:34:04.928259)


Review request for Default.


Summary
---

Ruby: Change DataBlock.hh
This patch changes DataBlock.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depende on
RubySystem have been moved to DataBlock.cc file.


Diffs
-

  src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Remove store buffer

2011-02-25 Thread Nilay Vaish 

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

Review request for Default.


Summary
---

Ruby: Remove store buffer
This patch removes the store buffer from Ruby. It is not in use currently.
Since libruby is being and store buffer makes calls to libruby, it is not
possible to maintain it until substantial changes are made.


Diffs
-

  src/mem/ruby/storebuffer/SConscript 4a59661d3fd1 
  src/mem/ruby/storebuffer/stb_interface.hh 4a59661d3fd1 
  src/mem/ruby/storebuffer/stb_interface.cc 4a59661d3fd1 
  src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
  src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 

Diff: http://reviews.m5sim.org/r/507/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: Remove libruby

2011-02-25 Thread Nilay Vaish 

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

(Updated 2011-02-25 08:32:18.235107)


Review request for Default.


Summary (updated)
---

Ruby: Remove libruby
This patch removes libruby from Ruby. It is no longer required. The
structures defined in this file have been moved to
slicc_interface/RubyRequest.hh file.


Diffs (updated)
-

  src/mem/ruby/SConscript 4a59661d3fd1 
  src/mem/ruby/libruby.hh 4a59661d3fd1 
  src/mem/ruby/libruby.cc 4a59661d3fd1 
  src/mem/ruby/profiler/Profiler.hh 4a59661d3fd1 
  src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 
  src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION 
  src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION 
  src/mem/ruby/slicc_interface/SConscript 4a59661d3fd1 
  src/mem/ruby/storebuffer/storebuffer.hh 4a59661d3fd1 
  src/mem/ruby/storebuffer/storebuffer.cc 4a59661d3fd1 
  src/mem/ruby/system/RubyPort.hh 4a59661d3fd1 
  src/mem/ruby/system/Sequencer.cc 4a59661d3fd1 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Remove libruby_internal.hh

2011-02-25 Thread Nilay Vaish 

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

Review request for Default.


Summary
---

Ruby: Remove libruby_internal.hh
This patch removes libruby_internal.hh and moves its contents to libruby.hh
file.


Diffs
-

  src/mem/ruby/libruby.cc 4a59661d3fd1 
  src/mem/ruby/libruby_internal.hh 4a59661d3fd1 
  src/mem/ruby/recorder/CacheRecorder.hh 4a59661d3fd1 
  src/mem/ruby/libruby.hh 4a59661d3fd1 
  src/mem/ruby/recorder/TraceRecord.hh 4a59661d3fd1 
  src/mem/ruby/recorder/Tracer.hh 4a59661d3fd1 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Change Address.hh

2011-02-25 Thread Nilay Vaish 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

Ruby: Change Address.hh
This patch changes Address.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depend on
RubySystem have been moved to Address.cc file.


Diffs
-

  src/mem/ruby/common/Address.hh UNKNOWN 
  src/mem/ruby/common/Address.cc UNKNOWN 
  src/mem/ruby/filters/BlockBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/BulkBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/LSB_CountingBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/MultiGrainBloomFilter.cc UNKNOWN 
  src/mem/ruby/filters/NonCountingBloomFilter.cc UNKNOWN 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Change DataBlock.hh

2011-02-25 Thread Nilay Vaish 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

Ruby: Change DataBlock.hh
This patch changes DataBlock.hh so that it is not dependent on RubySystem.
This dependence seems unecessary. All those functions that depende on
RubySystem have been moved to DataBlock.cc file.


Diffs
-

  src/cpu/testers/rubytest/RubyTester.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.hh 4a59661d3fd1 
  src/mem/ruby/common/DataBlock.cc 4a59661d3fd1 

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


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: O3CPU: Fix iqCount and lsqCount SMT fetch polic...

2011-02-25 Thread Timothy M. Jones 
changeset 4a59661d3fd1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4a59661d3fd1
description:
O3CPU: Fix iqCount and lsqCount SMT fetch policies.
Fixes two of the SMT fetch policies in O3CPU that were returning the 
count
of instructions in the IQ or LSQ rather than the thread ID to fetch 
from.

diffstat:

 src/cpu/o3/fetch_impl.hh |  18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diffs (55 lines):

diff -r ac1bd3d1aa54 -r 4a59661d3fd1 src/cpu/o3/fetch_impl.hh
--- a/src/cpu/o3/fetch_impl.hh  Thu Feb 24 02:14:45 2011 -0800
+++ b/src/cpu/o3/fetch_impl.hh  Fri Feb 25 13:50:29 2011 +
@@ -1404,19 +1404,22 @@
 ThreadID
 DefaultFetch::iqCount()
 {
-std::priority_queue PQ;
+std::priority_queue PQ;
+std::map threadMap;
 
 list::iterator threads = activeThreads->begin();
 list::iterator end = activeThreads->end();
 
 while (threads != end) {
 ThreadID tid = *threads++;
+unsigned iqCount = fromIEW->iewInfo[tid].iqCount;
 
-PQ.push(fromIEW->iewInfo[tid].iqCount);
+PQ.push(iqCount);
+threadMap[iqCount] = tid;
 }
 
 while (!PQ.empty()) {
-ThreadID high_pri = PQ.top();
+ThreadID high_pri = threadMap[PQ.top()];
 
 if (fetchStatus[high_pri] == Running ||
 fetchStatus[high_pri] == IcacheAccessComplete ||
@@ -1434,19 +1437,22 @@
 ThreadID
 DefaultFetch::lsqCount()
 {
-std::priority_queue PQ;
+std::priority_queue PQ;
+std::map threadMap;
 
 list::iterator threads = activeThreads->begin();
 list::iterator end = activeThreads->end();
 
 while (threads != end) {
 ThreadID tid = *threads++;
+unsigned ldstqCount = fromIEW->iewInfo[tid].ldstqCount;
 
-PQ.push(fromIEW->iewInfo[tid].ldstqCount);
+PQ.push(ldstqCount);
+threadMap[ldstqCount] = tid;
 }
 
 while (!PQ.empty()) {
-ThreadID high_pri = PQ.top();
+ThreadID high_pri = threadMap[PQ.top()];
 
 if (fetchStatus[high_pri] == Running ||
 fetchStatus[high_pri] == IcacheAccessComplete ||
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: O3: Implement memory mapped IPRs for O3.

2011-02-25 Thread Gabe Black 
I think there's a better than normal chance I introduced some bug with
this code, so I'd appreciate it if people could check it out.

Gabe

On 02/25/11 05:46, Gabe Black wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/502/
>
>
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt,
> and Nathan Binkert.
> By Gabe Black.
>
>
>   Description
>
> O3: Implement memory mapped IPRs for O3.
>
>
>   Diffs
>
> * src/cpu/o3/lsq_unit.hh (ac1bd3d1aa54)
> * src/cpu/o3/lsq_unit_impl.hh (ac1bd3d1aa54)
>
> View Diff 
>
>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: O3: Implement memory mapped IPRs for O3.

2011-02-25 Thread Gabe Black 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Implement memory mapped IPRs for O3.


Diffs
-

  src/cpu/o3/lsq_unit.hh ac1bd3d1aa54 
  src/cpu/o3/lsq_unit_impl.hh ac1bd3d1aa54 

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


Testing
---


Thanks,

Gabe

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: O3: Fix corner case squashing into the microcode ROM.

2011-02-25 Thread Gabe Black 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Fix corner case squashing into the microcode ROM.

When fetching from the microcode ROM, if the PC is set so that it isn't in the
cache block that's been fetched the CPU will get stuck. The fetch stage
notices that it's in the ROM so it doesn't try to fetch from the current PC.
It then later notices that it's outside of the current cache block so it skips
generating instructions expecting to continue once the right bytes have been
fetched. This change lets the fetch stage attempt to generate instructions,
and only checks if the bytes it's going to use are valid if it's really going
to use them.


Diffs
-

  src/cpu/o3/fetch_impl.hh ac1bd3d1aa54 

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


Testing
---


Thanks,

Gabe

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Cron /z/m5/regression/do-regression quick

2011-02-25 Thread Cron Daemon 
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 
passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/sim