24.22.5.1.1. gem5 completeAcc
completeAcc is boring on most simple store memory instructions, e.g. a simple STR:
Fault STRX64_IMM::completeAcc(PacketPtr pkt, ExecContext *xc,
Trace::InstRecord *traceData) const
{
return NoFault;
}
This is because the store does all of its job on completeAcc basically, creating the memory write request.
Loads however have non-trivial completeAcc, because now we have at the very least, to save the value read from memory into a CPU address.
Things are much more interesting however on more interesting loads, for example STXR (hand formatted here):
Fault STXRX64::completeAcc(PacketPtr pkt, ExecContext *xc,
Trace::InstRecord *traceData) const {
Fault fault = NoFault;
uint64_t XResult = 0;
uint32_t SevMailbox = 0;
uint32_t LLSCLock = 0;
uint64_t writeResult = pkt->req->getExtraData();
XResult = !writeResult; SevMailbox = 1; LLSCLock = 0;
if (fault == NoFault) {
{
uint64_t final_val = XResult;
xc->setIntRegOperand(this, 0, (XResult) & mask(aarch64 ? 64 : 32));
if (traceData) { traceData->setData(final_val); }
}
xc->setMiscRegOperand(this, 1, SevMailbox);
if (traceData) { traceData->setData(SevMailbox); }
xc->setMiscRegOperand(this, 2, LLSCLock);
if (traceData) { traceData->setData(LLSCLock); }
}
return fault;
}
From GDB on TimingSimpleCPU analysis: LDR stall we see that completeAcc gets called from TimingSimpleCPU::completeDataAccess.