Age | Commit message (Collapse) | Author |
|
|
|
|
|
object.
|
|
|
|
|
|
|
|
Some new functions and forward declarations are necessary to make things work
|
|
Make interrupts use the new wakeup method, and pull all of the interrupt
stuff into the cpu base class so that only the wakeup code needs to be updated.
I tried to make wakeup, wakeCPU, and the various other mechanisms for waking
and sleeping a little more sane, but I couldn't understand why the statistics
were changing the way they were. Maybe we'll try again some day.
|
|
|
|
There was really no reason that it should be FS only.
|
|
|
|
This is to prevent the assertion from firing if you have a large multicore.
Also make sure that it's not compiled in when NDEBUG is defined
|
|
redundancies with threadId() as their replacement.
|
|
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.
|
|
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.
|
|
comments.
|
|
|
|
Removing hwrei causes
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.
|
|
|
|
x86's Interrupts object.
|
|
|
|
|
|
For now, there is still a single global event queue, but this is
necessary for making the steps towards a parallelized m5.
|
|
--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
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
should configure their editors to not insert tabs
|
|
done to be consistent with its
python type of a latency. In addition, the multiple definitions of profile in the different cpu models caused
problems for intialization of the interval value. If a child class's profile value was defined, the parent
BaseCPU::ProfileEvent interval field would be initialized with a garbage value. The fix was to remove the
multiple redifitions of profile in the child CPU classes.
|
|
A whole bunch of stuff has been converted to use the new params stuff, but
the CPU wasn't one of them. While we're at it, make some things a bit
more stylish. Most of the work was done by Gabe, I just cleaned stuff up
a bit more at the end.
|
|
|
|
a newly created one can.
|
|
|
|
Force all non-default ports to provide a name and an
owner in the constructor.
|
|
--HG--
extra : convert_revision : 02775cfb460afe6df0df0938c62cccd93a71e775
|
|
This should help if somebody gets to the bug
fix before me (or someone else)...
--HG--
extra : convert_revision : 0ae64c58ef4f7b02996f31e9e9e6bfad344719e2
|
|
you are squashing from the current instruction # causing the thread exit.
--HG--
extra : convert_revision : ccbeece7dd1d5fee43f30ab19370908972113473
|
|
from the right point (#32 usually) instead of restarting at 0 and double-freeing.
Commented out assert line in free_list.hh that will check for when double-free condition
goes bad.
--HG--
extra : convert_revision : 08d5f9b6a874736e487d101e85c22aaa67bf59ae
|
|
--HG--
extra : convert_revision : cc0e62a5a337fd5bf332ad33bed61c0d505a936f
|
|
--HG--
extra : convert_revision : c7768d54d3f78685e93920069f5485083ca989c0
|
|
--HG--
extra : convert_revision : d811bf87d1a0bfc712942ecd3db1b48fc75257af
|
|
execute for next cycle. And the FUCompletion event has a lower priority than CPU tick event. It is called after the iew->tick() for current cycle has already been executed and the issueToExecuteQueue has already advanced this time. And assume the issueToExecuteLatency is 1, to catch up, the increasement should be made at access(-1) instead of access(0). Otherwise I found it could increase the actual op_latency of the instructions to execute by 1 cycle and potentially put the simulated CPU into a permanent idle state.
Signed-off by: Ali Saidi <saidi@eecs.umich.edu>
--HG--
extra : convert_revision : dafc16814383e8e8f8320845edf6ab2bcfed1e1d
|
|
--HG--
extra : convert_revision : 73b753e57c355b7e6873f047ddc8cb371c3136b7
|
|
--HG--
extra : convert_revision : 35d073d1279947d943a0290832e09a5268dd0b76
|
|
--HG--
extra : convert_revision : 5e89484b2ef21457ffba35ef959df999a28c5676
|
|
--HG--
extra : convert_revision : 16fb8d7f3fbc5f8f1fc3ed34427c3d90a3125ad0
|
|
"setShadowSet", "CacheOp"
--HG--
extra : convert_revision : a9ae8a7e62c27c2db16fd3cfa7a7f0bf5f0bf8ea
|