gem5  v21.1.0.2
Todo List
Namespace gem5
Member gem5::ArmISA::TableWalker::doL1Descriptor ()
: check sctlr.ha (bit[17]) if Hardware Access Flag is enabled if set, do l1.Desc.setAp0() instead of generating AccessFlag0
Member gem5::ArmISA::TableWalker::doL2Descriptor ()
: check sctlr.ha (bit[17]) if Hardware Access Flag is enabled if set, do l2.Desc.setAp0() instead of generating AccessFlag0
Member gem5::ArmISA::TableWalker::walk (const RequestPtr &req, ThreadContext *tc, uint16_t asid, vmid_t _vmid, bool _isHyp, BaseMMU::Mode mode, BaseMMU::Translation *_trans, bool timing, bool functional, bool secure, TLB::ArmTranslationType tranType, bool _stage2Req)
These should be cached or grabbed from cached copies in the TLB, all these miscreg reads are expensive
Member gem5::BaseCPU::instCnt
unify this with the counters that cpus individually keep
Member gem5::BaseTags::BaseTagStats::avgRefs
This should change to an average stat once we have them.
Member gem5::branch_prediction::BPredUnit::update (ThreadID tid, Addr instPC, bool taken, void *bp_history, bool squashed, const StaticInstPtr &inst, Addr corrTarget)=0
Make this update flexible enough to handle a global predictor.
Member gem5::EventQueue::serviceEvents (Tick when)
this assert is a good bug catcher. I need to make it true again.
Member gem5::IdeDisk::doDmaDataRead ()
we need to figure out what the delay actually will be
Member gem5::IdeDisk::doDmaDataWrite ()
we need to figure out what the delay actually will be
Member gem5::IdeDisk::serialize (CheckpointOut &cp) const override
need to serialized chunk generator stuff!!
Member gem5::IdeDisk::startCommand ()
make this a scheduled event to simulate disk delay
Member gem5::IdeDisk::unserialize (CheckpointIn &cp) override
need to serialized chunk generator stuff!!
Member gem5::IdeDisk::updateState (DevAction_t action)

change this to a scheduled event to simulate disk delay

change this to a scheduled event to simulate disk delay

Member gem5::NSGigE::cpuIntrPost (Tick when)
this warning should be removed and the intrTick code should be fixed.
Member gem5::NSGigE::rxKick ()

in reality, we should be able to start processing the packet as it arrives, and not have to wait for the full packet ot be in the receive fifo.

do we want to schedule a future kick?

Member gem5::NSGigE::txKick ()
do we want to schedule a future kick?
Member gem5::o3::DynInst::doneTargCalc ()
: Actually use this instruction.
Member gem5::o3::DynInst::renameSrcReg (int idx, PhysRegIdPtr renamed_src)
: add in whether or not the source register is ready.
Member gem5::o3::DynInst::setIntRegOperand (const StaticInst *si, int idx, RegVal val) override
: Make results into arrays so they can handle multiple dest registers.
Class gem5::o3::InstructionQueue
: Make IQ able to handle multiple FU pools.
Member gem5::o3::InstructionQueue::commitToIEWDelay
: Make there be a distinction between the delays within IEW.
Member gem5::o3::InstructionQueue::IQStats::numIssuedDist
: Need to create struct to track the entry time for each instruction.
Member gem5::o3::InstructionQueue::IQStats::statFuBusy
: Need to create struct to track the ready time for each instruction.
Member gem5::o3::InstructionQueue::listOrder
: Might be better to just move these entries around instead of creating new ones every time the position changes due to an instruction issuing. Not sure std::list supports this.
Member gem5::o3::LSQUnit::checkViolations (typename LoadQueue::iterator &loadIt, const DynInstPtr &inst)
in theory you only need to check an instruction that has executed however, there isn't a good way in the pipeline at the moment to check all instructions that will execute before the store writes back. Thus, like the implementation that came before it, we're overly conservative.
Class gem5::o3::UnifiedFreeList
: Give a better name to the base FP dependency.
Member gem5::ObjectMatch::domatch (const std::string &name) const
this should probably be changed to just use regular expression code
Class gem5::PMP
Add statistics and debug prints.
Member gem5::RefCounted::~RefCounted ()
Even if this were true, does it matter? Shouldn't the derived class indicate this? This only matters if we would ever choose to delete a "RefCounted *" which I doubt we'd ever do. We don't ever delete a "void *".
Member gem5::sinic::Base::cpuIntrPost (Tick when)
this warning should be removed and the intrTick code should be fixed.
Member gem5::sinic::Device::rxKick ()
do we want to schedule a future kick?
Member gem5::sinic::Device::txKick ()
do we want to schedule a future kick?
Member gem5::Trace::InstPBTrace::traceInst (ThreadContext *tc, StaticInstPtr si, TheISA::PCState pc)
if we are running multi-threaded I assume we'd need a lock here
Member gem5::VncServer::sendFrameBufferUpdate ()
this doesn't do anything smart and just sends the entire image
Member gem5::X86ISA::convX87XTagsToTags (uint8_t ftwx)
Reconstruct the correct state of stack positions instead of just valid/invalid.
File inifile.hh
Change comments to match documentation style.
Member TEST (StatsInfoTest, DISABLED_NameOldStyleTwice)
Test the behavior when set name is called twice on the same old-style info.
Member TEST (StatsGroupDeathTest, DISABLED_AddCycle)
Test that a group cannot be added in a cycle.

Generated on Tue Sep 21 2021 12:27:00 for gem5 by doxygen 1.8.17