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.
Bogus calls to ChunkGenerator with negative size were triggering
a new assertion that was added there.
Also did a little renaming and cleanup in the process.
I think readData() and writeData() were used for Erik's compression
work, but that code is gone, these aren't called anymore, and they
don't even really do what their names imply.
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.
The current EXTRAS will fail if the top level directory pointed to by EXTRAS
has a SConscript file in it. We allow this by including the directory name
of the EXTRA in the build directory which prevents a clash between
src/SConscript and extra/SConscript. Maintain compatibility with older uses
of EXTRAS by adding a -I for each top level extra directory.
We need to add a reference when an object is put on the C++ queue, and remove
a reference when the object is removed from the queue. This was not happening
before and caused a memory problem.
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.
the primary identifier for a hardware context should be contextId(). The
concept of threads within a CPU remains, in the form of threadId() because
sometimes you need to know which context within a cpu to manipulate.
SE. Process still keeps track of the tc's it owns, but registration occurs
with the System, this eases the way for system-wide context Ids based on
registration.
across the subclasses. generally make it so that member data is _cpuId and
accessor functions are cpuId(). The ID val comes from the python (default -1 if
none provided), and if it is -1, the index of cpuList will be given. this has
passed util/regress quick and se.py -n4 and fs.py -n4 as well as standard
switch.
The constructor no-longer schedules an event at construction and the implict conversion between int and bool was allowing the old code to compile without warning.
Signed-off By: Ali Saidi
the instruction after the hwrei to be fetched before the ITB/DTB_CM register is updated in a call pal
call sys and thus the translation fails because the user is attempting to access a super page address.
Minimally, it seems as though some sort of fetch stall or refetch after a hwrei is required. I think
this works currently because the hwrei uses the exec context interface, and the o3 stalls when that occurs.
Additionally, these changes don't update the LOCK register and probably break ll/sc. Both o3 changes were
removed since a great deal of manual patching would be required to only remove the hwrei change.
Since I never implemented a proper solution, put it back to something that
at least works for now. Once I add more event queues, I'll have to really
fix this though
The IntDev class is a base for anything that supports IntPins. IntPins allow
devices to generically trigger interrupts on a particular pin of an IntDev
device without having to know what the device is or what pin they're attached
to.
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.
If the same dictionary option is seen in several options, those
dictionaries are composed. If you define the same dictionary key in
multiple options, the system flags an error.
Also, clean up the jobfile code so that it is more debuggable.
Make them easier to express by only having the cxx_type parameter which
has the full namespace name, and drop the cxx_namespace thing.
Add support for multiple levels of namespace.
Since the early days of M5, an event needed to know which event queue
it was on, and that data was required at the time of construction of
the event object. In the future parallelized M5, this sort of
requirement does not work well since the proper event queue will not
always be known at the time of construction of an event. Now, events
are created, and the EventQueue itself has the schedule function,
e.g. eventq->schedule(event, when). To simplify the syntax, I created
a class called EventManager which holds a pointer to an EventQueue and
provides the schedule interface that is a proxy for the EventQueue.
The intent is that objects that frequently schedule events can be
derived from EventManager and then they have the schedule interface.
SimObject and Port are examples of objects that will become
EventManagers. The end result is that any SimObject can just call
schedule(event, when) and it will just call that SimObject's
eventq->schedule function. Of course, some objects may have more than
one EventQueue, so this interface might not be perfect for those, but
they should be relatively few.
I've done a few things here. First, I invoke the script a little bit
differently so that pdb doesn't get confused. Second, I've stored the
actual filename in the module's __file__ so that pdb can find the
source file on your machine.
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.
