| Age | Commit message (Collapse) | Author |
|---|
|
For now, there is still a single global event queue, but this is
necessary for making the steps towards a parallelized m5.
|
|
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.
|
|
NOTE: This code was written by Nathan Binkert in 2006 and is properly copyright
"The Regents of the University of Michigan"
|
|
Another good reason to avoid this is that swig will try to wrap the friend,
but it won't try to wrap a private static function.
|
|
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.
|
|
|
|
|
|
|
|
--HG--
rename : src/cpu/o3/sparc/cpu_builder.cc => src/cpu/o3/cpu_builder.cc
rename : src/cpu/o3/sparc/dyn_inst.cc => src/cpu/o3/dyn_inst.cc
rename : src/cpu/o3/sparc/impl.hh => src/cpu/o3/impl.hh
rename : src/cpu/o3/sparc/thread_context.cc => src/cpu/o3/thread_context.cc
|
|
--HG--
rename : src/cpu/o3/dyn_inst.hh => src/cpu/o3/dyn_inst_decl.hh
rename : src/cpu/o3/alpha/dyn_inst_impl.hh => src/cpu/o3/dyn_inst_impl.hh
|
|
|
|
|
|
|
|
|
|
object format.
|
|
|
|
While we're at it, make it possible to run main.py in a somewhat
standalone mode again so that we can test things without compiling.
|
|
panic rdpgpr/wrpgpr instructions until a better impl.
of MIPS shadow sets is available.
|
|
Also fix the unit tests so they actually compile correctly.
|
|
--HG--
rename : src/unittest/rangemaptest2.cc => src/unittest/rangemultimaptest.cc
|
|
|
|
|
|
and print better error messages when it doesn't.
|
|
|
|
|
|
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.
|
|
|
|
|
|
We should always refer to the specific ISA in that arch directory.
This is especially necessary if we're ever going to make it to the
point where we actually have heterogeneous systems.
|
|
We're never going to do an alpha platform other than the one we've got.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix the logic in the LSQ that determines if there are any stores to
write back. In the commit stage, check for thread specific writebacks
instead of just any writeback.
|
|
Just check CPU's nextPC before and after syscall and if it changes,
update this instruction's nextPC because the syscall must have changed
the nextPC.
|
|
The translate function simplifies code and removes some compiler
warnings in gcc 3.4
|
|
Swig code isn't quite perfect, so let's not turn on all of the warnings.
|
|
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.
|
|
|
|
|
|
|
