On Jul 14, 2011, at 3:21 PM, Gabe Black wrote: > Ok, I think I figured out what the problems were. First, I wasn't taking > advantage of the IsSquashAfter flag the ARM guys had added which clears > out the whole pipeline. I needed to be doing that whenever state changed > which would, for instance, affect how instruction fetches were > translated. That was relatively easy to fix, or at least it seemed to be. > > Then the second problem is more subtle. Basically, when you squash for > whatever reason (branch mispredict, exception, IsSquashAfter), I think > in all cases O3 starts fetch over again and refetches the instruction in > question. The next instruction, yes.
> This is fine a lot of the time, but there are two problems. > First, when dealing with microops, state may have updated which makes > fetching that instruction again impossible. Why? How does a real processor do this. Wasn't the whole point of the squash to make sure that the instruction see the new state? > In my case, an instruction > had stepped back down from kernel space to user space. Second, the > instruction itself may have changed. You could end up executing the > first half of one instruction and the second half of another. That > wouldn't make any sense. It seems like the instruction should be different. If the instruction is squashing mid-instruction, it probably should delay that squash till the end of the instruction, so the state is right. > > So what I'm thinking might be a solution is that whenever there's a > squash on a microop, O3 should send the macroop back to fetch along with > the restart PC. Then fetch can start fetching from that macroop again. > This has the side benefit that mispredicting a branch in microcode won't > cause an additional fetch which I speculate it does today. Do the micro-ops today even point to the macro-op that they come from? I still don't understand why the instruction can't be recreated if the ops is structured in a way that they wouldn't take a fault mid instruction. I assume it would be an option based on something because I'm pretty sure that this would break ARM when switches are made between thumb/arm state. FYI, the squashing instruction is sent back to fetch. Every time I tried to do something like this to deal with the IT state stuff it always sorta worked but ended up causing an issue in the long run. Ali _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
