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. Longer term I see a problem with the way PAL mode is communicated to the ITLB as well. First, the PC is passed as part of a request as a single address. This would make sense if the PC was the actual memory address used for the fetch, but that's already in the vaddr field. Generalized PCs have more structure than that. Second, this is the mangled PC which is only there to signal PAL mode in Alpha and has no current use in any other ISA. Even in Alpha only one bit actually matters. Carting this value around for this one (admittedly important) use is a waste. This is slightly a lie because the stride prefetcher also uses the PC field, but it looks like it could (and realistically would) use the paddr or vaddr instead. Third, its use depends on the fact that the magical property communicated by the PC carries over to all the instructions being fetched as part of that access, or in other words effectively the cache line. This is something that happens to work for Alpha but won't work generally. Fourth, if the PAL mode bit is pull out of the fetch address used by the CPUs so that they truly deal with memory addresses and not architectural PC values, the architectural PC, and effectively the PAL-ness of the Alpha PC, won't be accessible to the ITLB anymore. It looks like we can either have the PC based PAL mode bit in Alpha or more complete CPU model abstraction universally but not both. I don't have a better idea although I'm trying to think of one, but this definitely seems like something that can and should be improved on for all these reasons. One possible solution would be to store the actual PCState object in the request since that would at least be more general and allow getting the PAL bit out of the fetch address, but then we'd be carting around a handful of 64 bit values instead of just 1 when we still only care about a single bit only some of the time. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
