diff options
author | Steve Reinhardt <steve.reinhardt@amd.com> | 2016-01-17 18:27:46 -0800 |
---|---|---|
committer | Steve Reinhardt <steve.reinhardt@amd.com> | 2016-01-17 18:27:46 -0800 |
commit | 1b6355c89574c42c5b5f8014b994cf26dae4737d (patch) | |
tree | 53ef269f709829563084ba571504c8606ed7d89e /src/mem/ruby/slicc_interface/RubyRequest.hh | |
parent | 707275265f188a514d1d5673ed4c8d6495304962 (diff) | |
download | gem5-1b6355c89574c42c5b5f8014b994cf26dae4737d.tar.xz |
cpu. arch: add initiateMemRead() to ExecContext interface
For historical reasons, the ExecContext interface had a single
function, readMem(), that did two different things depending on
whether the ExecContext supported atomic memory mode (i.e.,
AtomicSimpleCPU) or timing memory mode (all the other models).
In the former case, it actually performed a memory read; in the
latter case, it merely initiated a read access, and the read
completion did not happen until later when a response packet
arrived from the memory system.
This led to some confusing things, including timing accesses
being required to provide a pointer for the return data even
though that pointer was only used in atomic mode.
This patch splits this interface, adding a new initiateMemRead()
function to the ExecContext interface to replace the timing-mode
use of readMem().
For consistency and clarity, the readMemTiming() helper function
in the ISA definitions is renamed to initiateMemRead() as well.
For x86, where the access size is passed in explicitly, we can
also get rid of the data parameter at this level. For other ISAs,
where the access size is determined from the type of the data
parameter, we have to keep the parameter for that purpose.
Diffstat (limited to 'src/mem/ruby/slicc_interface/RubyRequest.hh')
0 files changed, 0 insertions, 0 deletions