> On 2010-11-10 08:07:39, Steve Reinhardt wrote: > > So it looks like whether you call setMiscReg() or setMiscRegNoEffect() then > > you buffer the update and call setMiscReg() later... i.e., even if you > > called setMiscRegNoEffect() originally you end up calling setMiscReg() at > > commit. > > > > Are there ever cases where we call setMiscRegNoEffect() from an > > instruction? I thought it was strictly for things like system > > initialization and restoring from checkpoints anyway... maybe we don't need > > it in the ExecContext interface. > > > > Also, I see that these predate your change, but why do we need both the > > setMiscReg() calls and the setMiscRegOperand() calls? Is one of them > > deprecated? Can we take this opportunity to update the comments to > > distinguish them? We shouldn't have two different functions for which the > > descriptive comment is completely identical IMO. > > > > Ali Saidi wrote: > You're right... The only place i can find an xc using > setMiscRegNoEffect() is locked_mem.hh for alpha and what is the exact copy of > it for MIPS. It seems like that could be setMiscReg(). The implementation for > LOCKED_ADDR is identical (there are no effects). Perhaps we should remove it > from the xc. My guess was that it was used with the intention of making it > cheaper by not having the cpu squash when it happens, but in reality that > didn't work out. > > The difference between the operand and no operand version is that the > operand version gets the dest misc register from the instruction while the > non-operand one expects it passed in as a parameter. One should be > implemented in terms of the other, but both seem to be used. > > Gabe Black wrote: > Yeah, I think generally setMiscRegOperand is going to be called from > generated code and setMiscReg is going to be used by handwritten code where > the index is provided directly.
Ok... I removed the NoEffect versions from the exec context and changed the *Operand versions to just call their non-operand versions which cleans up the code some. Alpha has no problem with these changes, but they do uncover a bug with SPARC that somehow worked, but it's amazing that it did. The ASI register changes the type of instruction that is executing (e.g. one ASI is a type of prefetch vs. load vs. load with a different addressing mode etc). The types are decoded from the ASI bits in the ExtMachInst which are inserted by the pre-decoder. The trouble is that these bits are inserted in "fetch" which is before rename so the IsSerializing flags don't prevent it from happening. Thus, while the wrasi instruction can be marked as Serializing fetch already has read the old value and created the instructions based on the old ASI. When wrasi commits the old instructions flow through the rest of the pipeline and that isn't great. It's amazing that all the code sequences that Gabe used to run on the sparc/o3 model never ran into this issue. With the current code if you executed a alternating wrasi and load w/asi instructions you would get some very odd results. Anyway, the question becomes how do we fix this??? My current solution is to add an instruction flag that after commit flushes the CPU. Although, I don't know if this is enough and what other surprises I'll run into. Thoughts? Ali - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/298/#review473 ----------------------------------------------------------- On 2010-11-08 15:46:52, Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/298/ > ----------------------------------------------------------- > > (Updated 2010-11-08 15:46:52) > > > Review request for Default. > > > Summary > ------- > > O3: Make all instructions that write a misc register not perform the write > until commit. > > ARM Instructions updating cumulative flags (ARM FP exceptions and saturation > flags) are not serialized. > > Added aliases for ARM FP exceptions and saturation flags in FPSCR. > > > Diffs > ----- > > src/arch/arm/isa.cc f61e079ad05e > src/arch/arm/isa/insts/fp.isa f61e079ad05e > src/arch/arm/isa/insts/neon.isa f61e079ad05e > src/arch/arm/isa/operands.isa f61e079ad05e > src/arch/arm/miscregs.hh f61e079ad05e > src/cpu/o3/commit_impl.hh f61e079ad05e > src/cpu/o3/dyn_inst.hh f61e079ad05e > src/cpu/o3/dyn_inst_impl.hh f61e079ad05e > > Diff: http://reviews.m5sim.org/r/298/diff > > > Testing > ------- > > > Thanks, > > Ali > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
