History log of /gem5/src/mem/ruby/common/NetDest.cc
Revision Date Author Comments
# 11793:ef606668d247 09-Nov-2016 Brandon Potter <brandon.potter@amd.com>

style: [patch 1/22] use /r/3648/ to reorganize includes


# 10348:c91b23c72d5e 03-Sep-2014 Andreas Hansson <andreas.hansson@arm.com>

base: Use the global Mersenne twister throughout

This patch tidies up random number generation to ensure that it is
done consistently throughout the code base. In essence this involves a
clean-up of Ruby, and some code simplifications in the traffic
generator.

As part of this patch a bunch of skewed distributions (off-by-one etc)
have been fixed.

Note that a single global random number generator is used, and that
the object instantiation order will impact the behaviour (the sequence
of numbers will be unaffected, but if module A calles random before
module B then they would obviously see a different outcome). The
dependency on the instantiation order is true in any case due to the
execution-model of gem5, so we leave it as is. Also note that the
global ranom generator is not thread safe at this point.

Regressions using the memtest, TrafficGen or any Ruby tester are
affected and will be updated accordingly.


# 10005:8c2b0dc16ccd 04-Jan-2014 Nilay Vaish <nilay@cs.wisc.edu>

ruby: add support for clusters

A cluster over here means a set of controllers that can be accessed only by a
certain set of cores. For example, consider a two level hierarchy. Assume
there are 4 L1 controllers (private) and 2 L2 controllers. We can have two
different hierarchies here:

a. the address space is partitioned between the two L2 controllers. Each L1
controller accesses both the L2 controllers. In this case, each L1 controller
is a cluster initself.

b. both the L2 controllers can cache any address. An L1 controller has access
to only one of the L2 controllers. In this case, each L2 controller
along with the L1 controllers that access it, form a cluster.

This patch allows for each controller to have a cluster ID, which is 0 by
default. By setting the cluster ID properly, one can instantiate hierarchies
with clusters. Note that the coherence protocol might have to be changed as
well.


# 10004:5d8b72563869 04-Jan-2014 Nilay Vaish <nilay@cs.wisc.edu>

ruby: some small changes


# 9138:b4d0bdb52694 01-Aug-2012 Jason Power <powerjg@cs.wisc.edu>

Ruby NetDest: add assert for bad element in netdest


# 8946:fb6c89334b86 14-Apr-2012 Andreas Hansson <andreas.hansson@arm.com>

clang/gcc: Fix compilation issues with clang 3.0 and gcc 4.6

This patch addresses a number of minor issues that cause problems when
compiling with clang >= 3.0 and gcc >= 4.6. Most importantly, it
avoids using the deprecated ext/hash_map and instead uses
unordered_map (and similarly so for the hash_set). To make use of the
new STL containers, g++ and clang has to be invoked with "-std=c++0x",
and this is now added for all gcc versions >= 4.6, and for clang >=
3.0. For gcc >= 4.3 and <= 4.5 and clang <= 3.0 we use the tr1
unordered_map to avoid the deprecation warning.

The addition of c++0x in turn causes a few problems, as the
compiler is more stringent and adds a number of new warnings. Below,
the most important issues are enumerated:

1) the use of namespaces is more strict, e.g. for isnan, and all
headers opening the entire namespace std are now fixed.

2) another other issue caused by the more stringent compiler is the
narrowing of the embedded python, which used to be a char array,
and is now unsigned char since there were values larger than 128.

3) a particularly odd issue that arose with the new c++0x behaviour is
found in range.hh, where the operator< causes gcc to complain about
the template type parsing (the "<" is interpreted as the beginning
of a template argument), and the problem seems to be related to the
begin/end members introduced for the range-type iteration, which is
a new feature in c++11.

As a minor update, this patch also fixes the build flags for the clang
debug target that used to be shared with gcc and incorrectly use
"-ggdb".


# 8485:7a9a7f2a3d46 03-Aug-2011 Nilay Vaish<nilay@cs.wisc.edu>

Ruby: Remove files and includes not in use


# 8229:78bf55f23338 15-Apr-2011 Nathan Binkert <nate@binkert.org>

includes: sort all includes


# 7805:f249937228b5 23-Dec-2010 Nilay Vaish<nilay@cs.wisc.edu>

This patch removes the WARN_* and ERROR_* from src/mem/ruby/common/Debug.hh file. These statements have been replaced with warn(), panic() and fatal() defined in src/base/misc.hh


# 7454:3a3e8e8cce1b 11-Jun-2010 Nathan Binkert <nate@binkert.org>

ruby: get rid of Vector and use STL
add a couple of helper functions to base for deleteing all pointers in
a container and outputting containers to a stream


# 7089:9ea24d102d66 01-Jun-2010 Nathan Binkert <nate@binkert.org>

style: clean up ruby's Set class

Further cleanup should probably be done to make this class be non-Ruby
specific and put it in src/base.

There are probably several cases where this class is used, std::bitset
could be used instead.


# 7055:4e24742201d7 02-Apr-2010 Nathan Binkert <nate@binkert.org>

ruby: get "using namespace" out of headers
In addition to obvious changes, this required a slight change to the slicc
grammar to allow types with :: in them. Otherwise slicc barfs on std::string
which we need for the headers that slicc generates.


# 7039:bc0b6ea676b5 22-Mar-2010 Nathan Binkert <nate@binkert.org>

ruby: style pass


# 6797:7bf0a839c237 18-Nov-2009 Brad Beckmann <Brad.Beckmann@amd.com>

Resurrection of the CMP token protocol to GEM5


# 6372:f1a41ea3bbab 18-Jul-2009 Derek Hower <drh5@cs.wisc.edu>

ruby: removed all refs to old RubyConfig


# 6284:a63d1dc4c820 06-Jul-2009 Nathan Binkert <nate@binkert.org>

ruby: replace strings that were missed in original ruby import.


# 6154:6bb54dcb940e 11-May-2009 Nathan Binkert <nate@binkert.org>

ruby: Make ruby #includes use full paths to the files they're including.
This basically means changing all #include statements and changing
autogenerated code so that it generates the correct paths. Because
slicc generates #includes, I had to hard code the include paths to
mem/protocol.


# 6145:15cca6ab723a 11-May-2009 Nathan Binkert <nate@binkert.org>

ruby: Import ruby and slicc from GEMS

We eventually plan to replace the m5 cache hierarchy with the GEMS
hierarchy, but for now we will make both live alongside eachother.