| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
If a fault was returned by the CPU when a store initiated it's write, the
store instruction would ignore the fault. This change fixes that.
|
|
The previous commit on functional access support in Ruby did not have
some of the files required. This patch adds those files to the repository.
|
|
This patch rpovides functional access support in Ruby. Currently only
the M5Port of RubyPort supports functional accesses. The support for
functional through the PioPort will be added as a separate patch.
|
|
The patch corrects the print statement which prints the current and
the next pc. Instead of the next upc, the next pc was being printed.
|
|
|
|
the -/+ signs were flipped for nmsub_s, nmsub_d, and nmadd_d
|
|
|
|
|
|
this will safeguard future code from trying to remove
from the list twice. That code wouldnt break but would
waste time.
|
|
|
|
|
|
handle them like we do in FS mode, by blocking the TLB until the fault
is handled by the fault->invoke()
|
|
|
|
|
|
|
|
|
|
implement clearfetchbufferfunction
extend predecoder to use multiple threads and clear those on trap
|
|
this will make sure we get the correct view of a FP register
|
|
|
|
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
|
|
|
|
|
