> On March 30, 2013, 7:31 a.m., Ali Saidi wrote: > > While this seems harmless enough, I wonder if there is some interaction > > between faults/interrupts and the instruction that we should worry about. I > > haven't given it enough thought to say either way, but it seems like it > > could be a concern.
I thought about it somewhat, since IT blocks are required to be able to handle faults and return to execution properly within an IT block. It seems the gem5 solution is probably similar to what a real processor implementation would use, appending the IT state to the PC. So an exception/interrupt within an IT block would just return and the decoder would pick off the extra IT bits from the PC (that detail how to predicate up to the next 3 ops). If the exception/interrupt was just prior to the IT instruction, it would just get sent to the decoder like normal. I was thinking more on the "discarding nops at decode" part. The only case I think that could give that trouble is self-modifying code, since you'd want to track instruction addresses to know if a snooped write changed a currently executing instruction. But gem5 doesn't really provide that now anyway and you could use cheaper structures to perform that operation (since false positives would be ok). - Mitch ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1805/#review4177 ----------------------------------------------------------- On March 29, 2013, 7:47 p.m., Mitch Hayenga wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1805/ > ----------------------------------------------------------- > > (Updated March 29, 2013, 7:47 p.m.) > > > Review request for Default. > > > Description > ------- > > Mark ARM IT (if-then) instructions as nops. > > ARM's IT instructions predicate up to the next 4 instructions on various > condition codes. IT instructions really just send control signals to the > decoder, after decode they do not read or write any registers. Marking them > as nops (along with the other patch that drops nops at decode) saves > execution resources and bandwidth. > > > Diffs > ----- > > src/arch/arm/isa/insts/misc.isa 47591444a7c5 > > Diff: http://reviews.gem5.org/r/1805/diff/ > > > Testing > ------- > > A fast libquantum run. > > > Thanks, > > Mitch Hayenga > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
