Re: [gem5-dev] Review Request 3083: ruby: slicc: remove nextLineHack from Type.py

[Jason Power]

> On Sept. 2, 2015, 7:41 p.m., Jason Power wrote:
> > Do you know what this was used for? I've never encountered this, but it 
> > probably had a good reason to be there at some point...
> 
> Nilay Vaish wrote:
> None of the current protocols use it.  The line has seen not any changes 
> since SLICC was first
> merged into the repository.  I certainly don't like the name of the 
> 'feature'.  I think
> it is safe to drop it.

At a minimum we should wait for Brad to comment, since he may know what its 
purpose was.


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3083/#review7095
---


On Sept. 2, 2015, 12:52 a.m., Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3083/
> ---
> 
> (Updated Sept. 2, 2015, 12:52 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11078:249cacaa1d02
> ---
> ruby: slicc: remove nextLineHack from Type.py
> 
> 
> Diffs
> -
> 
>   src/mem/slicc/symbols/Type.py 2763a59c73ff 
> 
> Diff: http://reviews.gem5.org/r/3083/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

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

Re: [gem5-dev] Review Request 3014: ruby: set: reimplement using std::bitset

[Tony Gutierrez]

> On Aug. 17, 2015, 2:37 p.m., Jieming Yin wrote:
> > src/mem/ruby/common/NetDest.cc, line 113
> > 
> >
> > m_bits[i].getSize() returns NUMBER_BITS_PER_SET, which is 64 for all 
> > machine types. In case of broadcast, all bits are set in m_bits. Will it 
> > cause problem if the number of actual components is smaller than 
> > NUMBER_BITS_PER_SET? Perhapse in class Set, add a size parameter is a 
> > better idea to prevent such situation.
> 
> Nilay Vaish wrote:
> I have added back the m_nSize variable.

Maybe I'm missing something here, but why is m_nSize necessary for broadcast? 
It seemed to me that broadcast() only looks to see if all bits for the set are 
set, and doesn't determine how many to components to broadcast to. So it seems 
fine to me to have the logic of broadcast() be such that it will be considered 
a broadcast if all bits are set, and not a broadcast otherwise, the fact that 
there are extra bits set doesn't seem to matter.


- Tony


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3014/#review6991
---


On Aug. 31, 2015, 7:58 a.m., Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3014/
> ---
> 
> (Updated Aug. 31, 2015, 7:58 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11077:0dfa7e7d62d0
> ---
> ruby: set: reimplement using std::bitset
> The current Set data structure is slow and therefore is being reimplemented
> using std::bitset. A maximum limit of 64 is being set on the number of
> controllers of each type.  This means that for simulating a system with more
> controllers of a given type, one would need to change the value of the 
> variable
> NUMBER_BITS_PER_SET
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/common/Set.hh 969113566d50 
>   src/mem/ruby/common/Set.cc 969113566d50 
>   src/mem/ruby/common/NetDest.hh 969113566d50 
>   src/mem/ruby/common/SConscript 969113566d50 
> 
> Diff: http://reviews.gem5.org/r/3014/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Nilay Vaish
> 
>

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

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Tony Gutierrez]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2965/#review7107
---


Are they comments on this? We'd like to ship this soon.

- Tony Gutierrez


On July 13, 2015, noon, David Hashe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2965/
> ---
> 
> (Updated July 13, 2015, noon)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10923:8bdfe8dd9c2b
> ---
> rename System.{hh,cc} to RubySystem.{hh,cc}
> 
> The eventual aim of this change is to pass RubySystem pointers through to 
> objects generated from the SLICC protocol code.
> 
> Because some of these objects need to dereference their RubySystem pointers, 
> they need access to the System.hh header file.
> 
> In src/mem/ruby/SConscript, the MakeInclude function creates single-line 
> header files in the build directory that do nothing except include the 
> corresponding header file from the source tree.
> 
> However, SLICC also generates a list of header files from its symbol table, 
> and writes it to mem/protocol/Types.hh in the build directory. This code 
> assumes that the header file name is the same as the class name.
> 
> The end result of this is the many of the generated slicc files try to 
> include RubySystem.hh, when the file they really need is System.hh. The path 
> of least resistence is just to rename System.hh to RubySystem.hh.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubySystem.cc PRE-CREATION 
>   src/mem/slicc/symbols/StateMachine.py 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/Sequencer.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/SConscript 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/CacheMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/DirectoryMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.hh PRE-CREATION 
>   src/mem/ruby/system/RubyPort.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/CacheRecorder.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/WireBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/TimerTable.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/slicc/symbols/Type.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/slicc_interface/AbstractController.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/SimpleNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/Network.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/MessageBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/BulkBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/BlockBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/common/DataBlock.cc 

[gem5-dev] Review Request 3089: cpu: Create record type enum for elastic traces

[Curtis Dunham]

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

Review request for Default.


Repository: gem5


Description
---

This patch replaces the booleans that specified the elastic trace record
type with an enum type. The source of change is the proto message for
elastic trace where the enum is introduced. The struct definitions in the
elastic trace probe listener as well as the Trace CPU replace the boleans
with the proto message enum.

The patch does not impact functionality, but traces are not compatible with
previous version. This is preparation for adding new types of records in
subsequent patches.

This patch adds to the "Elastic Traces" patch series of RB3026-3031.


Diffs
-

  util/decode_inst_dep_trace.py PRE-CREATION 
  util/encode_inst_dep_trace.py PRE-CREATION 
  src/cpu/trace/trace_cpu.cc PRE-CREATION 
  src/proto/inst_dep_record.proto PRE-CREATION 
  src/cpu/o3/probe/elastic_trace.hh PRE-CREATION 
  src/cpu/o3/probe/elastic_trace.cc PRE-CREATION 
  src/cpu/trace/trace_cpu.hh PRE-CREATION 

Diff: http://reviews.gem5.org/r/3089/diff/


Testing
---


Thanks,

Curtis Dunham

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

[gem5-dev] Review Request 3090: cpu: Support virtual addr in elastic traces

[Curtis Dunham]

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

Review request for Default.


Repository: gem5


Description
---

This patch adds support to optionally capture the virtual address and asid
for load/store instructions in the elastic traces. If they are present in
the traces, Trace CPU will set those fields of the request during replay.

This patch adds to the "Elastic Traces" patch series of RB3026-3031,3089.


Diffs
-

  src/cpu/o3/probe/ElasticTrace.py PRE-CREATION 
  src/cpu/o3/probe/elastic_trace.hh PRE-CREATION 
  src/cpu/o3/probe/elastic_trace.cc PRE-CREATION 
  src/cpu/trace/trace_cpu.hh PRE-CREATION 
  src/cpu/trace/trace_cpu.cc PRE-CREATION 
  src/proto/inst_dep_record.proto PRE-CREATION 
  util/decode_inst_dep_trace.py PRE-CREATION 
  util/encode_inst_dep_trace.py PRE-CREATION 

Diff: http://reviews.gem5.org/r/3090/diff/


Testing
---


Thanks,

Curtis Dunham

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

Re: [gem5-dev] On ReviewBoard: Elastic Traces

[Curtis Dunham]

Hello again,
RB30{89,90} have been added to this patch series.  The original six haven't 
received any feedback in the last three weeks.  We plan to move forward with 
these soon so have a look if you're interested.

Thanks,
Curtis Dunham

-Original Message-
From: Curtis Dunham
Sent: Tuesday, August 11, 2015 4:43 PM
To: gem5-dev@gem5.org
Subject: On ReviewBoard: Elastic Traces

Hello everyone,
I have posted to RB a 6-patch set (RB3026 - RB3031) implementing "Elastic 
Traces".  The two primary components of this functionality are (1) enhancements 
to the O3 CPU model to collect these traces using Probe Points and (2) a "Trace 
CPU" to play the traces back.  The value proposition of Elastic Traces is that 
they track data dependences and resource dependences within the CPU; this 
fidelity improvement allows the Trace CPU to provide useful results across 
varying memory system/interconnect configurations from a single trace.

Looking forward to any feedback.


Thanks,
Curtis Dunham

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

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

Re: [gem5-dev] Review Request 3014: ruby: set: reimplement using std::bitset

[Gutierrez, Anthony]

I see. So it needs the bits in the set to identify which controllers to send 
to, and it can’t just send to all controllers? That is, the on-chip doesn’t 
have a list of all known controllers that it could use to identify where the 
messages should be sent?

From: Nilay Vaish [mailto:nore...@gem5.org] On Behalf Of Nilay Vaish
Sent: Thursday, September 03, 2015 1:56 PM
To: Nilay Vaish; Gutierrez, Anthony; Default; Jieming Yin
Subject: Re: Review Request 3014: ruby: set: reimplement using std::bitset

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



On August 17th, 2015, 9:37 p.m. UTC, Jieming Yin wrote:
src/mem/ruby/common/NetDest.cc
 (Diff revision 1)


NetDest::getAllDest()

113


int id = MachineType_base_number((MachineType)i) + j;

113


int id = MachineType_base_number((MachineType)i) + j;


m_bits[i].getSize() returns NUMBER_BITS_PER_SET, which is 64 for all machine 
types. In case of broadcast, all bits are set in m_bits. Will it cause problem 
if the number of actual components is smaller than NUMBER_BITS_PER_SET? 
Perhapse in class Set, add a size parameter is a better idea to prevent such 
situation.

On August 31st, 2015, 2:59 p.m. UTC, Nilay Vaish wrote:

I have added back the m_nSize variable.

On September 3rd, 2015, 6:05 p.m. UTC, Tony Gutierrez wrote:

Maybe I'm missing something here, but why is m_nSize necessary for broadcast? 
It seemed to me that broadcast() only looks to see if all bits for the set are 
set, and doesn't determine how many to components to broadcast to. So it seems 
fine to me to have the logic of broadcast() be such that it will be considered 
a broadcast if all bits are set, and not a broadcast otherwise, the fact that 
there are extra bits set doesn't seem to matter.

On Thu, 3 Sep 2015, Tony Gutierrez wrote:



Maybe I'm missing something here, but why is m_nSize necessary for broadcast? 
It seemed to me that broadcast() only looks to see if all



Because of the way broadcast is implemented by the on-chip network.



bits for the set are set, and doesn't determine how many to components to 
broadcast to. So it seems fine to me to have the logic of broadcast() be such 
that it will be considered a broadcast if all bits are set, and not a broadcast 
otherwise, the fact that there are extra bits set doesn't seem to matter.



The on-chip will try to send the broadcast message to controllers corresponding

to bits that are set.  Hence, if there is no size variable to determine the 
maximum

number of bits in use, then messages will be sent to non-existent controllers.


- Nilay


On August 31st, 2015, 2:58 p.m. UTC, Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.

Updated Aug. 31, 2015, 2:58 p.m.
Repository: gem5
Description

Changeset 11077:0dfa7e7d62d0

---

ruby: set: reimplement using std::bitset

The current Set data structure is slow and therefore is being reimplemented

using std::bitset. A maximum limit of 64 is being set on the number of

controllers of each type.  This means that for simulating a system with more

controllers of a given type, one would need to change the value of the variable

NUMBER_BITS_PER_SET


Diffs

  *   src/mem/ruby/common/Set.hh (969113566d50)
  *   src/mem/ruby/common/Set.cc (969113566d50)
  *   src/mem/ruby/common/NetDest.hh (969113566d50)
  *   src/mem/ruby/common/SConscript (969113566d50)

View Diff


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

[gem5-dev] changeset in gem5: Added tag stable_2015_09_03 for changeset 60e...

[Nilay Vaish]

changeset bfc99bc87a79 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bfc99bc87a79
description:
Added tag stable_2015_09_03 for changeset 60eb3fef9c2d

diffstat:

 .hgtags |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (8 lines):

diff -r 2763a59c73ff -r bfc99bc87a79 .hgtags
--- a/.hgtags   Tue Sep 01 15:50:33 2015 -0500
+++ b/.hgtags   Thu Sep 03 15:38:46 2015 -0500
@@ -27,3 +27,4 @@
 cb2e6950956d475da97b04c41f19769ce2e8541a stable_2014_08_26
 bdb307e8be54a5808a9af2537e9261d88de6ed1b stable_2014_12_14
 e1794974515011f81f8d0fda7543ba3360a12c9b stable_2015_04_15
+60eb3fef9c2d51cf98cdb5501ee0c4ac0efe6eae stable_2015_09_03
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Gutierrez, Anthony]

We can do either hg mv, or hg rm and hg add. What is preferred?

From: Nilay Vaish [mailto:nore...@gem5.org] On Behalf Of Nilay Vaish
Sent: Thursday, September 03, 2015 1:51 PM
To: Nilay Vaish; Gutierrez, Anthony; Hashe, David; Default
Subject: Re: Review Request 2965: rename System.{hh,cc} to RubySystem.{hh,cc}

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



On September 3rd, 2015, 6:36 p.m. UTC, Tony Gutierrez wrote:

Are they comments on this? We'd like to ship this soon.

Has hg mv been used to move those two files?


- Nilay


On July 13th, 2015, 7 p.m. UTC, David Hashe wrote:
Review request for Default.
By David Hashe.

Updated July 13, 2015, 7 p.m.
Repository: gem5
Description

Changeset 10923:8bdfe8dd9c2b

---

rename System.{hh,cc} to RubySystem.{hh,cc}



The eventual aim of this change is to pass RubySystem pointers through to 
objects generated from the SLICC protocol code.



Because some of these objects need to dereference their RubySystem pointers, 
they need access to the System.hh header file.



In src/mem/ruby/SConscript, the MakeInclude function creates single-line header 
files in the build directory that do nothing except include the corresponding 
header file from the source tree.



However, SLICC also generates a list of header files from its symbol table, and 
writes it to mem/protocol/Types.hh in the build directory. This code assumes 
that the header file name is the same as the class name.



The end result of this is the many of the generated slicc files try to include 
RubySystem.hh, when the file they really need is System.hh. The path of least 
resistence is just to rename System.hh to RubySystem.hh.


Diffs

  *   src/mem/ruby/system/RubySystem.cc (PRE-CREATION)
  *   src/mem/slicc/symbols/StateMachine.py 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/System.cc (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/System.hh (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/Sequencer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/SConscript (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/RubySystem.py 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/CacheMemory.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/BankedArray.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/BankedArray.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/DirectoryMemory.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/Prefetcher.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/RubySystem.hh (PRE-CREATION)
  *   src/mem/ruby/system/RubyPort.hh (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/DMASequencer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/DMASequencer.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/system/CacheRecorder.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/WireBuffer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/TimerTable.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/RubyMemoryControl.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/RubyMemoryControl.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/structures/Prefetcher.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/slicc/symbols/Type.py (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/slicc_interface/AbstractController.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/Throttle.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/Throttle.hh 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/simple/SimpleNetwork.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/Network.cc (5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/network/MessageBuffer.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/NonCountingBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/MultiGrainBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/BulkBloomFilter.cc 
(5ee72f4b293152dd0c75ab402a49696d6903e604)
  *   src/mem/ruby/filters/BlockBloomFilter.cc 

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Tony Gutierrez]

> On Sept. 3, 2015, 11:36 a.m., Tony Gutierrez wrote:
> > Are they comments on this? We'd like to ship this soon.
> 
> Nilay Vaish wrote:
> Has hg mv been used to move those two files?

We can do hg mv or hg rm/hg add. What is preferred?


- Tony


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2965/#review7107
---


On July 13, 2015, noon, David Hashe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2965/
> ---
> 
> (Updated July 13, 2015, noon)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10923:8bdfe8dd9c2b
> ---
> rename System.{hh,cc} to RubySystem.{hh,cc}
> 
> The eventual aim of this change is to pass RubySystem pointers through to 
> objects generated from the SLICC protocol code.
> 
> Because some of these objects need to dereference their RubySystem pointers, 
> they need access to the System.hh header file.
> 
> In src/mem/ruby/SConscript, the MakeInclude function creates single-line 
> header files in the build directory that do nothing except include the 
> corresponding header file from the source tree.
> 
> However, SLICC also generates a list of header files from its symbol table, 
> and writes it to mem/protocol/Types.hh in the build directory. This code 
> assumes that the header file name is the same as the class name.
> 
> The end result of this is the many of the generated slicc files try to 
> include RubySystem.hh, when the file they really need is System.hh. The path 
> of least resistence is just to rename System.hh to RubySystem.hh.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubySystem.cc PRE-CREATION 
>   src/mem/slicc/symbols/StateMachine.py 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/Sequencer.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/SConscript 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/CacheMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/DirectoryMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.hh PRE-CREATION 
>   src/mem/ruby/system/RubyPort.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/CacheRecorder.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/WireBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/TimerTable.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/slicc/symbols/Type.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/slicc_interface/AbstractController.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/SimpleNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/Network.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/MessageBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Nilay Vaish]

On Thu, 3 Sep 2015, Tony Gutierrez wrote:





On Sept. 3, 2015, 11:36 a.m., Tony Gutierrez wrote:

Are they comments on this? We'd like to ship this soon.


Nilay Vaish wrote:
Has hg mv been used to move those two files?


We can do hg mv or hg rm/hg add. What is preferred?



hg rm/hg add would lose all the history.  Certainly hg mv should be 
preferred.


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

Re: [gem5-dev] Review Request 2965: rename System.{hh, cc} to RubySystem.{hh, cc}

[Nilay Vaish]

> On Sept. 3, 2015, 6:36 p.m., Tony Gutierrez wrote:
> > Are they comments on this? We'd like to ship this soon.

Has hg mv been used to move those two files?


- Nilay


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2965/#review7107
---


On July 13, 2015, 7 p.m., David Hashe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2965/
> ---
> 
> (Updated July 13, 2015, 7 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10923:8bdfe8dd9c2b
> ---
> rename System.{hh,cc} to RubySystem.{hh,cc}
> 
> The eventual aim of this change is to pass RubySystem pointers through to 
> objects generated from the SLICC protocol code.
> 
> Because some of these objects need to dereference their RubySystem pointers, 
> they need access to the System.hh header file.
> 
> In src/mem/ruby/SConscript, the MakeInclude function creates single-line 
> header files in the build directory that do nothing except include the 
> corresponding header file from the source tree.
> 
> However, SLICC also generates a list of header files from its symbol table, 
> and writes it to mem/protocol/Types.hh in the build directory. This code 
> assumes that the header file name is the same as the class name.
> 
> The end result of this is the many of the generated slicc files try to 
> include RubySystem.hh, when the file they really need is System.hh. The path 
> of least resistence is just to rename System.hh to RubySystem.hh.
> 
> 
> Diffs
> -
> 
>   src/mem/ruby/system/RubySystem.cc PRE-CREATION 
>   src/mem/slicc/symbols/StateMachine.py 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/System.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/Sequencer.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/SConscript 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/CacheMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/BankedArray.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/DirectoryMemory.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/RubySystem.hh PRE-CREATION 
>   src/mem/ruby/system/RubyPort.hh 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/DMASequencer.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/system/CacheRecorder.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/WireBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/TimerTable.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/RubyMemoryControl.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/structures/Prefetcher.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/slicc/symbols/Type.py 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/slicc_interface/AbstractController.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/Throttle.hh 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/simple/SimpleNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/Network.cc 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/network/MessageBuffer.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/NonCountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/MultiGrainBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/LSB_CountingBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   src/mem/ruby/filters/BulkBloomFilter.cc 
> 5ee72f4b293152dd0c75ab402a49696d6903e604 
>   

[gem5-dev] Cron <m5test@zizzer> /z/m5/regression/do-regression quick

[Cron Daemon]

* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed. [ CXX] ALPHA_MOESI_CMP_directory/mem/ruby/common/Address.cc -> .o
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed. [ CXX] ALPHA_MOESI_CMP_token/mem/ruby/common/Address.cc -> .o
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
 * 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing 
passed.= Statistics differences =
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed.
* 

Re: [gem5-dev] Review Request 2511: dev: cirrus: Add a simplified device model for the cirrus graphics device.

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2511/#review7112
---


Rebased diff.

- Gabe Black


On Sept. 3, 2015, 10:26 p.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2511/
> ---
> 
> (Updated Sept. 3, 2015, 10:26 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10608:45b160d14246
> ---
> dev: cirrus: Add a simplified device model for the cirrus graphics device.
> 
> All control register accesses are dropped on the floor. If used with KVM, the
> frame buffer is set up as a memory like region to keep performance from
> tanking. If a VNC server is configured, the buffer is marked dirty once every
> simulated 100ms.
> 
> 
> Diffs
> -
> 
>   configs/common/FSConfig.py 95eb22928d0f 
> 
> Diff: http://reviews.gem5.org/r/2511/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

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

Re: [gem5-dev] Review Request 2511: dev: cirrus: Add a simplified device model for the cirrus graphics device.

[Gabe Black]

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

(Updated Sept. 3, 2015, 10:26 p.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 10608:45b160d14246
---
dev: cirrus: Add a simplified device model for the cirrus graphics device.

All control register accesses are dropped on the floor. If used with KVM, the
frame buffer is set up as a memory like region to keep performance from
tanking. If a VNC server is configured, the buffer is marked dirty once every
simulated 100ms.


Diffs (updated)
-

  configs/common/FSConfig.py 95eb22928d0f 

Diff: http://reviews.gem5.org/r/2511/diff/


Testing
---


Thanks,

Gabe Black

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

Re: [gem5-dev] Review Request 2525: x86: Add a cirrus graphics adapter to x86 systems.

[Gabe Black]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2525/#review7111
---


Rebased diff.

- Gabe Black


On Sept. 3, 2015, 10:25 p.m., Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2525/
> ---
> 
> (Updated Sept. 3, 2015, 10:25 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 10562:ee3ae920f5b5
> ---
> x86: Add a cirrus graphics adapter to x86 systems.
> 
> This required reworking how the functions which hook up the system are
> organized slightly. They really need more a more substantial overhaul, but
> that's outside of the scope of this change.
> 
> 
> Diffs
> -
> 
>   src/dev/Cirrus.py PRE-CREATION 
>   src/dev/SConscript 95eb22928d0f 
>   src/dev/cirrus.hh PRE-CREATION 
>   src/dev/cirrus.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/2525/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe Black
> 
>

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

Re: [gem5-dev] Review Request 2525: x86: Add a cirrus graphics adapter to x86 systems.

[Gabe Black]

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

(Updated Sept. 3, 2015, 10:25 p.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 10562:ee3ae920f5b5
---
x86: Add a cirrus graphics adapter to x86 systems.

This required reworking how the functions which hook up the system are
organized slightly. They really need more a more substantial overhaul, but
that's outside of the scope of this change.


Diffs (updated)
-

  src/dev/Cirrus.py PRE-CREATION 
  src/dev/SConscript 95eb22928d0f 
  src/dev/cirrus.hh PRE-CREATION 
  src/dev/cirrus.cc PRE-CREATION 

Diff: http://reviews.gem5.org/r/2525/diff/


Testing
---


Thanks,

Gabe Black

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

Re: [gem5-dev] Updates to gem5-stable

[Nilay Vaish]

On Wed, 5 Aug 2015, Joel Hestness wrote:


Hi Nilay,
 One major concern is that we just pushed fixes for Ruby checkpointing to
mainline (i.e. http://repo.gem5.org/gem5?cmd=changeset;node=72781d410e48). Tim
Jones suggested that gem5 changeset 10524 was the origin of some
checkpointing bugs, so gem5-stable might not currently support Ruby
checkpointing in a stable way. However, it would be nice to be able to rely
on gem5-stable for correct checkpointing (I believe checkpointing in Ruby
was still broken at changeset 10875?).

 Perhaps we could merge the Ruby checkpointing patches into gem5-stable?
Or it might make sense to wait a bit longer before updating stable, and at
that time, update past gem5 10991? The former would avoid introducing any
latent bugs from recent changesets.

 Joel



On Tue, Aug 4, 2015 at 10:04 AM, Nilay Vaish  wrote:


Hello everyone

Nearly four months have passed since we updated gem5-stable.  I am
planning to move it forward on 15th August.  The changeset I have on my
mind is:

changeset:   10875:60eb3fef9c2d
user:Jason Power 
date:Thu Jun 25 11:58:28 2015 -0500
summary: Ruby: Remove assert in RubyPort retry list logic

This would add about 208 patches to gem5-stable.  Since we no longer
maintain the same changeset order between gem5 and gem5-stable, I am
willing to entertain requests for cherry picking bug fixes that were pushed
after the changeset suggested.





I have updated gem5-stable to the changeset I mentioned.

Joel, I tried merging the patches that fix checkpointing, but they do not 
apply cleanly on top of 10875:60eb3fef9c2d.  So those patches would be 
merged with gem5-stable next time we update it.


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

Re: [gem5-dev] Updates to gem5-stable

[Joel Hestness]

Ok!

Some notes for the next update: I've been hammering changeset
11061:25b53a7195f7, and can confirm that it appears Ruby checkpoint and
restore is working with timing and O3 CPUs, both with and without the Ruby
backing store.


  Joel



On Thu, Sep 3, 2015 at 3:44 PM, Nilay Vaish  wrote:

> On Wed, 5 Aug 2015, Joel Hestness wrote:
>
> Hi Nilay,
>>  One major concern is that we just pushed fixes for Ruby checkpointing to
>> mainline (i.e. http://repo.gem5.org/gem5?cmd=changeset;node=72781d410e48).
>> Tim
>> Jones suggested that gem5 changeset 10524 was the origin of some
>> checkpointing bugs, so gem5-stable might not currently support Ruby
>> checkpointing in a stable way. However, it would be nice to be able to
>> rely
>> on gem5-stable for correct checkpointing (I believe checkpointing in Ruby
>> was still broken at changeset 10875?).
>>
>>  Perhaps we could merge the Ruby checkpointing patches into gem5-stable?
>> Or it might make sense to wait a bit longer before updating stable, and at
>> that time, update past gem5 10991? The former would avoid introducing any
>> latent bugs from recent changesets.
>>
>>  Joel
>>
>>
>>
>> On Tue, Aug 4, 2015 at 10:04 AM, Nilay Vaish  wrote:
>>
>> Hello everyone
>>>
>>> Nearly four months have passed since we updated gem5-stable.  I am
>>> planning to move it forward on 15th August.  The changeset I have on my
>>> mind is:
>>>
>>> changeset:   10875:60eb3fef9c2d
>>> user:Jason Power 
>>> date:Thu Jun 25 11:58:28 2015 -0500
>>> summary: Ruby: Remove assert in RubyPort retry list logic
>>>
>>> This would add about 208 patches to gem5-stable.  Since we no longer
>>> maintain the same changeset order between gem5 and gem5-stable, I am
>>> willing to entertain requests for cherry picking bug fixes that were
>>> pushed
>>> after the changeset suggested.
>>>
>>>
>>>
>
> I have updated gem5-stable to the changeset I mentioned.
>
> Joel, I tried merging the patches that fix checkpointing, but they do not
> apply cleanly on top of 10875:60eb3fef9c2d.  So those patches would be
> merged with gem5-stable next time we update it.
>
>
> --
> Nilay
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>



-- 
  Joel Hestness
  PhD Candidate, Computer Architecture
  Dept. of Computer Science, University of Wisconsin - Madison
  http://pages.cs.wisc.edu/~hestness/
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev