The renamings in changesets 8f5993cf (2015-03-23) "mem: rename
Locked/LOCKED to LockedRMW/LOCKED_RMW" and fdd4a895 (2015-07-03)
"mem: Split WriteInvalidateReq into write and invalidate" broke the
SST connector. This commit repeats those renamings in ext/sst.
Add revision 9adf9d6e2d889a483a92136c96eb8a434d360561 of NoMali-model
from https://github.com/ARM-software/nomali-model. This library
implements the register interface of the Mali T6xx/T7xx series GPUs,
but doesn't do any rendering. It can be used to hide the effects of
software rendering.
This patch adds an example configuration in ext/sst/tests/ that allows
an SST/gem5 instance to simulate a 4-core AArch64 system with SST's
memHierarchy components providing all the caches and memories.
This patch adds a connector that allows gem5 to be used as a component
in SST (Structural Simulation Toolkit, sst-simulator.org). At a high
level, this allows memory traffic to pass between the two simulators.
SST Links are roughly analogous to gem5 Ports, although Links do not
have a notion of master and slave. This distinction is important to
gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave
must be used, and similarly when connecting the memory side of SST cache
to a gem5 port (for memory <-> I/O), an ExternalMaster must be used.
These connectors handle the administrative aspects of gem5
(initialization, simulation, shutdown) as well as translating SST's
MemEvents into gem5 Packets and vice-versa.
This patch bumps DRAMPower to commit
19433a6897ede4bbb19b06694faa8589b5a6569a which contains a small fix
for clang, and a work-around for LTO with gcc 4.6.
This patch updates fputils to the latest revision (6a47fd8358) from
the upstream repository (github.com/andysan/fputils). Most notably,
this includes changes that export a limited set of 64-bit float
manipulation and avoids a warning about unused 64-bit floats in clang.
This patch extensively modifies DSENT so that it can be accessed using Python.
To access the Python interface, DSENT needs to compiled as a shared library.
For this purpose a CMakeLists.txt file has been added. Some of the code that
is not required is being removed.
This patch adds a tool called DSENT to the ext/ directory. DSENT
is a tool that models power and area for on-chip networks. The next
patch adds a script for using the tool.
This patch adds the open-source (BSD 3-clause) tool DRAMPower, commit
8d3cf4bbb10aa202d850ef5e5e3e4f53aa668fa6, to be built as a part of the
simulator. We have chosen this specific version of DRAMPower as it
provides the necessary functionality, and future updates will be
coordinated with the DRAMPower development team. The files added only
include the bits needed to build the library, thus excluding all
memory specifications, traces, and the stand-alone DRAMPower
command-line tool.
A future patch includes the DRAMPower functionality in the DRAM
controller, to enable on-line DRAM power modelling, and avoid using
post-processing of traces.
Add a regression tester to McPAT. Joel Hestness wrote these tests and Yasuko
Eckert modified them to reflect the new McPAT interface and other changes
the previous patch made.
This patch includes software engineering changes and some generic bug fixes
Joel Hestness and Yasuko Eckert made to McPAT 0.8. There are still known
issues/concernts we did not have a chance to address in this patch.
High-level changes in this patch include:
1) Making XML parsing modular and hierarchical:
- Shift parsing responsibility into the components
- Read XML in a (mostly) context-free recursive manner so that McPAT input
files can contain arbitrary component hierarchies
2) Making power, energy, and area calculations a hierarchical and recursive
process
- Components track their subcomponents and recursively call compute
functions in stages
- Make C++ object hierarchy reflect inheritance of classes of components
with similar structures
- Simplify computeArea() and computeEnergy() functions to eliminate
successive calls to calculate separate TDP vs. runtime energy
- Remove Processor component (now unnecessary) and introduce a more abstract
System component
3) Standardizing McPAT output across all components
- Use a single, common data structure for storing and printing McPAT output
- Recursively call print functions through component hierarchy
4) For caches, allow splitting data array and tag array reads and writes for
better accuracy
5) Improving the usability of CACTI by printing more helpful warning and error
messages
6) Minor: Impose more rigorous code style for clarity (more work still to be
done)
Overall, these changes greatly reduce the amount of replicated code, and they
improve McPAT runtime and decrease memory footprint.
Very rarely does anyone ever mess with PLY code, and when
such a need arises, the developer can reenable this flag in
their working tree.
This will eliminate the "generating LALR tables" message
during compilation and temporary parser.out file as well.
This patch adds DRAMSim2 as a memory controller by wrapping the
external library and creating a sublass of AbstractMemory that bridges
between the semantics of gem5 and the DRAMSim2 interface.
The DRAMSim2 wrapper extracts the clock period from the config
file. There is no way of extracting this information from DRAMSim2
itself, so we simply read the same config file and get it from there.
To properly model the response queue, the wrapper keeps track of how
many transactions are in the actual controller, and how many are
stacking up waiting to be sent back as responses (in the wrapper). The
latter requires us to move away from the queued port and manage the
packets ourselves. This is due to DRAMSim2 not having any flow control
on the response path.
DRAMSim2 assumes that the transactions it is given are matching the
burst size of the choosen memory. The wrapper checks to ensure the
cache line size of the system matches the burst size of DRAMSim2 as
there are currently no provisions to split the system requests. In
theory we could allow a cache line size smaller than the burst size,
but that would lead to inefficient use of the DRAM, so for not we
fatal also in this case.
Note: AArch64 and AArch32 interworking is not supported. If you use an AArch64
kernel you are restricted to AArch64 user-mode binaries. This will be addressed
in a later patch.
Note: Virtualization is only supported in AArch32 mode. This will also be fixed
in a later patch.
Contributors:
Giacomo Gabrielli (TrustZone, LPAE, system-level AArch64, AArch64 NEON, validation)
Thomas Grocutt (AArch32 Virtualization, AArch64 FP, validation)
Mbou Eyole (AArch64 NEON, validation)
Ali Saidi (AArch64 Linux support, code integration, validation)
Edmund Grimley-Evans (AArch64 FP)
William Wang (AArch64 Linux support)
Rene De Jong (AArch64 Linux support, performance opt.)
Matt Horsnell (AArch64 MP, validation)
Matt Evans (device models, code integration, validation)
Chris Adeniyi-Jones (AArch64 syscall-emulation)
Prakash Ramrakhyani (validation)
Dam Sunwoo (validation)
Chander Sudanthi (validation)
Stephan Diestelhorst (validation)
Andreas Hansson (code integration, performance opt.)
Eric Van Hensbergen (performance opt.)
Gabe Black
The fp code relies on C99, and depending on gcc version, the default
is to use c89. This patch adds -std=c99 when using gcc to ensure the
code is compiled in ISO C99 mode.
This changeset updates the external library to git revision
52b6190b4e. This update includes changes that fix compilation errors
on old gcc versions and fixes to test a case that affect ICC.
This changeset includes libfputils from revision bbf0d61d75. This
library can be used to convert to and from 80-bit floats and query the
type of an 80-bit float, which is needed to support the x87 FPU.
this patch adds libfdt, a library necessary for supporting
flattened device tree support in current and future versions of
the linux/android kernel for ARM.
This patch checks that the compiler in use is either gcc >= 4.4 or
clang >= 2.9. and enables building with --std=c++0x in all cases. As a
consequence, we can tidy up the hashmap and always have static_assert
available. If anyone wants to use alternative compilers, icc for
example supports c++0x to a similar level and could be added if
needed.
This patch opens up for a more elaborate use of c++0x features that
are present in gcc 4.4 and clang 2.9, e.g. auto typed variables,
variadic templates, rvalues and move semantics, and strongly typed
enums. There will be no going back on this one...
This patch fixes a linking error that occurs when using clang/llvm in
combination with older versions of glibc. The fix involves adding
-std=gnu89 to the command line when compiling libelf as clang defaults
to c99, causing issues with the symbols in sysmacros.h being defined
multiple times.
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".
This patch adds the necessary flags to the SConstruct and SConscript
files for compiling using clang 2.9 and later (on Ubuntu et al and OSX
XCode 4.2), and also cleans up a bunch of compiler warnings found by
clang. Most of the warnings are related to hidden virtual functions,
comparisons with unsigneds >= 0, and if-statements with empty
bodies. A number of mismatches between struct and class are also
fixed. clang 2.8 is not working as it has problems with class names
that occur in multiple namespaces (e.g. Statistics in
kernel_stats.hh).
clang has a bug (http://llvm.org/bugs/show_bug.cgi?id=7247) which
causes confusion between the container std::set and the function
Packet::set, and this is currently addressed by not including the
entire namespace std, but rather selecting e.g. "using std::vector" in
the appropriate places.
Adaptations to make gem5 compile and run on OSX 10.7.2, with a stock
gcc 4.2.1 and the remaining dependencies from macports, i.e. python
2.7,.2 swig 2.0.4, mercurial 2.0. The changes include an adaptation of
the SConstruct to handle non-library linker flags, and Darwin-specific
code to find the memory usage of gem5. A number of Ruby files relied
on ambigious uint (without the 32 suffix) which caused compilation
errors.
env is used as a local variable all over the place and sometimes it is
easy to get confused as to whether the global env or local env is being
used. This will become especially important when I change the way we
support our variants.
1) -L is automatically added, so don't do it ourselves
2) prepend the paths for gzstream and libelf so they are certain to
come first. The problem is that python might add /usr/lib to the path
and the user might have a locally installed version of libelf installed.
This allows me to clean things up so we are up to date with respect to
deprecated features. There are many features scheduled for permanent failure
in scons 2.0 and 0.98.1 provides the most compatability for that. It
also paves the way for some nice new features that I will add soon
The gzstream package provides an ostream-interface for writing gzipped files.
The package comes from:
http://www.cs.unc.edu/Research/compgeom/gzstream/
And is distributed under the LGPL license. Both the license and version
information has been preservered, though all other files in the package have
been purged. Minor modifications to the code have been made. The output module
detects when a filename ends in .gz and constructs an ogzstream object instead
of an ofstream object. This works for both the create(...) and find(...)
commands. Additionally, since gzstream objects needs to be closed to ensure
proper file termination, I have the output deconstructor deleting all ostream's
that it manages on behalf of find(...). At the moment, the only output file
that I know this functionality works for is stats, i.e. by specifying
"--stats-file=m5stats.txt.gz" on the command line.
Targets look like libm5_debug.so. This target can be dynamically
linked into another C++ program and provide just about all of the M5
features. Additionally, this library is a standalone module that can
be imported into python with an "import libm5_debug" type command
line.
SConstruct:
export env after we've set CC/CXX
ext/libelf/SConscript:
pull in the CC/CXX variables from env. Use gm4 if it exists
ext/libelf/elf_begin.c:
ext/libelf/libelf_allocate.c:
include errno.h instead of sys/errno.h
ext/libelf/elf_common.h:
use the more standard uintX_t
ext/libelf/elf_strptr.c:
ext/libelf/elf_update.c:
include sysmacros.h on Solaris for roundup()
--HG--
extra : convert_revision : ea1aab834029399c445dfa4c9f78febf2c3d8f0c
