| Age | Commit message (Collapse) | Author |
|---|
|
The DTB expects the correct PC in the ThreadContext
but how if the memory accesses are speculative? Shouldn't
we send along the requestor's PC to the translate functions?
|
|
including IPR accesses and store-conditionals. These class of instructions will not
execute correctly in a superscalar machine
|
|
|
|
Just "dfault" gets confusing while debugging. Why not
differentiate whether it's an access violation or page
fault
|
|
if a faulting instruction reaches an execution unit,
then ignore it and pass it through the pipeline.
Once we recognize the fault in the graduation unit,
dont allow a second fault to creep in on the same cycle.
|
|
handle "snoop" port registration as well as functional
port setup for FS mode
|
|
use a dummy instruction to facilitate the squash after
the interrupts trap
|
|
Before graduating an instruction, explicitly check fault
by making the fault check it's own separate command
that can be put on an instruction schedule.
|
|
|
|
|
|
this always changes the PC and is basically an impromptu branch instruction. why
not speculate on this instead of always be forced to mispredict/squash after the
hwrei gets resolved?
The InOrder model needs this marked as "isControl" so it knows to update the PC
after the ALU executes it. If this isnt marked as control, then it's going to
force the model to check the PC of every instruction at commit (what O3 does?),
and that would be a wasteful check for a very high percentage of instructions.
|
|
make syscall a SE mode only functionality
copy over basic FS functions (hwrei) to make FS compile
|
|
speculative load/store pipelines can reenable this
|
|
calculate blocks in use for the fetch buffer to figure out how many total blocks
are pending
|
|
Sharing the FP value w/the integer values was giving inconsistent results esp. when
their is a 32-bit integer register matched w/a 64-bit float value
|
|
define a syscallContext to schedule the syscall and then use syscall() to actually perform the action
|
|
segfault was caused by squashed multiply thats in the process of an event.
use isProcessing flag to handle this and cleanup the MDU code
|
|
|
|
remove events in the resource pool that can be called from the CPU event, since the CPU
event is scheduled at the same time at the resource pool event.
----
Also, match the resPool event function names to the cpu event function names
----
|
|
once a ST is sent off, it's OK to keep processing, however it's a little more
complicated to handle the packet acknowledging the store is completed
|
|
once a ST is sent off, it's OK to keep processing, however it's a little more
complicated to handle the packet acknowledging the store is completed
|
|
also, cleanup comments for gem5.fast compilation
|
|
dont treat read() and write() fields as mut. exclusive
|
|
only update BTB on a taken branch and update branch predictor w/pcstate from instruction
---
only pay attention to branch predictor updates if the the inst. is in fact a branch
|
|
define separate priority resource pool squash and graduate events
|
|
|
|
this causes forwarding a bad value register value
|
|
|
|
|
|
use it in reg. dep. tracking
|
|
dont use offset to calculate this but rather an enum
that can be updated
|
|
|
|
|
|
implement a clean interface to handle branch misprediction and eventually all pipeline
flushing
|
|
valgrind complains and its a potential source of instability, so go ahead
and set it to 0 to start
|
|
The DynInst was not performing the host-to-guest translation
which ended up breaking stores for SPARC
|
|
formerly, this was implicit when you accessed the execution unit
or the use-def unit but it's better that this just be something
that a user can specify.
|
|
|
|
add find and end functions for inst. schedules
that can search by stage number
|
|
keep stats for int/float reg file usage instead
of aggregating across reg file types
|
|
make handling of speculative and nonspeculative insts
more explicit
|
|
Architectures like SPARC need to read the window pointer
in order to figure out it's register dependence. However,
this may not get updated until after an instruction gets
executed, so now we lazily detect the register dependence
in the EXE stage (execution unit or use_def). This
makes sure we get the mapping after the most current change.
|
|
provide a sanity check for someone coding
a new architecture
|
|
call trap function when a fault is received
|
|
ignore writes to the ISA zero register
|
|
|
|
get rid of accessing iterators (for instructions) by reference
|
|
|
|
clean up control flow to make it easier to understand
|
|
|
