Gabe Black wrote: > I'm trying to factor out PAL mode from O3, and I found the following > line > > http://repo.m5sim.org/m5/file/fc12f4d657f0/src/cpu/o3/fetch_impl.hh#l579 > > } else if (interruptPending && !(fetch_PC & 0x3)) { > > > which is basically making fetch stop fetching once it sees that an > interrupt is pending and it's no longer fetching PAL mode code. Why is > that there? If interrupts are blocked while in PAL mode, why doesn't O3 > just rely on commit waiting until committed state is out of PAL mode and > then start handling the interrupt? This behavior would be very annoying > and perhaps impossible to preserve in an ISA agnostic way and I'd really > like to just get rid of it, but if there's a good reason for it I'll > have to be more creative. It innocuously sits there inert for SPARC and > MIPS, but for ARM in thumb mode with 16 bit instructions and especially > X86 where the PC can be anything with no special meaning this will cause > a serious problem. This is something I'd like to have straightened out > in the short to medium term. >
On further consideration "serious problem" might be an overstatement. I think what might happen is that O3 will arbitrarily fetch or not fetch instructions based on whatever the lower 2 bits of the PC are while an interrupt is pending. Things should still work (although that's just a guess), but seemingly arbitrary behavior is probably best avoided. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
