Sorry for not responding sooner. I meant to, but then I got pulled in a different direction. I don't think this explanation is correct. For microops that are from the microcode ROM with no corresponding macroop, they'd all have a dummy ExtMachInst but it should be well defined and deterministic. If they're from the microcode ROM but have a macroop (ie. if it's a really complicated macroop) then they'd have its ExtMachInst instead. What specific problems are you seeing? There may be a bad pointer or unintentionally uninitialized data involved.
Gabe On 04/14/12 16:18, Steve Reinhardt wrote: > So the issue is when you have a microop that's not part of a macroop? It's > understandable how that could be an issue. > > Nevertheless, (1) it's misleading to be printing dummy machInst information > and (2) worse yet, IMO, since the dummy information is apparently random, > it's leading to spurious differences in tracediff. > > Is there an easy way to identify when the machInst is bogus so we can > suppress printing it in the DPRINTF? > > Steve > > On Sat, Apr 14, 2012 at 3:08 PM, Nilay Vaish <[email protected]> wrote: > >> After reading decoder.cc, it seems that in case of execution being inside >> microcode rom, you can get some dummy value (defined in x86_traits.hh) for >> machInst. Otherwise you should get correct value for machInst. >> >> -- >> Nilay >> >> >> On Thu, 12 Apr 2012, Steve Reinhardt wrote: >> >> I'm running into some problems where I'm tracediffing two x86 runs and >>> getting some seemingly spurious differences in the decode output. >>> >>> The key question I have is: what is the meaning of the machInst field of a >>> micro op? >>> >>> The problem seems to be in the code below (from >>> http://repo.gem5.org/gem5/**file/d062cc7a8bdf/src/cpu/** >>> simple/base.cc#l403<http://repo.gem5.org/gem5/file/d062cc7a8bdf/src/cpu/simple/base.cc#l403> >>> ). >>> Note that if we're executing a macroop, then curMacroStaticInst has the >>> correct machInst, but the DPRINTF at the bottom is printing the machInst >>> from the microop (via curStaticInst), which appears in at least some cases >>> to be garbage. >>> >>> Am I diagnosing this properly? Any ideas on a fix? >>> >>> Steve >>> >>> >>> >>> //If we decoded an instruction and it's microcoded, start pulling >>> //out micro ops >>> if (instPtr && instPtr->isMacroop()) { >>> curMacroStaticInst = instPtr; >>> curStaticInst = >>> curMacroStaticInst->**fetchMicroop(pcState.microPC()**); >>> } else { >>> curStaticInst = instPtr; >>> } >>> } else { >>> //Read the next micro op from the macro op >>> curStaticInst = curMacroStaticInst->** >>> fetchMicroop(pcState.microPC()**); >>> } >>> >>> //If we decoded an instruction this "tick", record information about it. >>> if(curStaticInst) >>> { >>> #if TRACING_ON >>> traceData = tracer->getInstRecord(curTick(**), tc, >>> curStaticInst, thread->pcState(), curMacroStaticInst); >>> >>> DPRINTF(Decode,"Decode: Decoded %s instruction: 0x%x\n", >>> curStaticInst->getName(), curStaticInst->machInst); >>> #endif // TRACING_ON >>> } >>> ______________________________**_________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >>> >>> ______________________________**_________________ >> gem5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/**listinfo/gem5-dev<http://m5sim.org/mailman/listinfo/gem5-dev> >> > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
