| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Enable more or less takes the place of check, but also allows stats to
do some other configuration. Prepare moves all of the code that readies
a stat for dumping into a separate function in preparation for supporting
serialization of certain pieces of statistics data.
While we're at it, clean up the visitor code and some of the python code.
|
|
This basically works by taking advantage of the curiously recurring template
pattern in an intelligent way so as to reduce the number of lines of code
and hopefully make things a little bit clearer.
|
|
|
|
|
|
|
|
This provides an easy way to provide the callbacks into the data side
of things from the info side of things. Rename Wrap to DataWrap so it
is more easily distinguishable from InfoWrap
|
|
Parent and Child are bad names. Derived and Base are better.
|
|
|
|
|
|
generic stages so w/o an ID there is no way to differentiate buffers when debugging
|
|
|
|
|
|
|
|
Just use the stuff directly and things ought to be more clear
|
|
Basically, this means renaming several things called data to info, which
is information about the statistics. Things that are named data now are
actual data stored for the statistic.
|
|
|
|
|
|
|
|
information about an error.
|
|
printing.
|
|
|
|
payload; add function to split packet at last known header
|
|
|
|
|
|
|
|
it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
|
|
|
|
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.
|
|
I did some of the flags and assertions wrong. Thanks to Brad Beckmann
for pointing this out. I should have run the opt regressions instead
of the fast. I also screwed up some of the logical functions in the Flags
class.
|
|
In many cases it might be preferable to use bitset, but this object
allows the user more easily manipulate groups of flags because the
underlying type (e.g. uint64_t) is exposed.
|
|
In DEBUG mode, this does a dynamic_cast and asserts that the result is
non null. Otherwise, it just does a static_cast. Again, this is only
intended for cases where the cast should always succeed and what's
desired is a debugging check to make sure.
|
|
Would have saved me much debugging time if these
had been in there previously.
|
|
|
|
|
|
The major thrust of this change is to limit the amount of code
duplication surrounding the code for these functions. This code also
adds two new message types called info and hack. Info is meant to be
less harsh than warn so people don't get confused and start thinking
that the simulator is broken. Hack is a way for people to add runtime
messages indicating that the simulator just executed a code "hack"
that should probably be fixed. The benefit of knowing about these
code hacks is that it will let people know what sorts of inaccuracies
or potential bugs might be entering their experiments. Finally, I've
added some flags to turn on and off these message types so command
line options can change them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Even though we're not incorrect about operator precedence, let's add
some parens in some particularly confusing places to placate GCC 4.3
so that we don't have to turn the warning off. Agreed that this is a
bit of a pain for those users who get the order of operations correct,
but it is likely to prevent bugs in certain cases.
|
|
|
|
In the future, it would be nice to put the O3CPU into its own
namespace so that we don't end up hardcoding pointers to the global
namespace.
|
|
These functions keep trying to read and write until all data has been
transferred, or an error occurrs. In the case where an end of file
hasn't been reached, but all of the bytes have not been read/written,
try again. On EINTR, try again.
|
|
|
|
|
