> 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? Interrupts cannot be taken during palmode. I'm not sure how this would be handled from commit. What needs to happen is that fetch cannot be redirected to the interrupt handler until the CPU exits PAL (i.e. the pal routine needs to finish without being interrupted at all).
> 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. We could have a more generic ISA specific function areInterruptsEnabled() which would be inlined to return true in most ISAs. > 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. Seems perfectly reasonable and not too difficult to me. > 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'm not clear on why Alpha couldn't keep the PAL mode bit in the PC. Seems that any ISA independent code (i.e. the CPU models) when asking for the PC should get the masked value. The ISA dependent code (i.e. stuff in arch/alpha) should get the unfiltered one. Functions like areInterruptsEnabled would be machine dependent and would have access to the ExecContext and the PC structure to grab the pal mode bit. > 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. Perhaps the general PCState object should be broken up into sub objects. I.e. a single PC object for a single PC that can encapsulate information about that PC. The PCState object could be build from those. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
