Hi folks. Currently, when you need to advance a PC in gem5, you need to take an instruction object of the appropriate type and pass the PC object to its advancePC method.
The idea here was that some PCs are unidimensional, or in other words have only one component (a simple address for instance), and some are multidimensional (an address plus micropc) and which dimension(s) you need to advance the PC in depend on factors like whether an instruction is microcoded, and also whether that instruction is the final microop in its macroop. If an ISA which doesn't use microcode (only POWER and MIPS, I think?) you save a little bit of effort by not bothering to check all that microcode business since you know for sure that it won't matter. In the other ISAs like x86, you can check whether the instruction you grabbed was either non-microcoded (advance the regular PC), microcoded and in the middle (advance the microPC only) or microcoded and at the end (advance the regular PC, reset the microPC). Also instructions which are not possibly microcoded could skip the check as well. This is ok but a little bit clunky since the PCState object is not self sufficient, and the instructions themselves have to have logic for advancing the PC. Instead, I'm thinking about making the arch decoder (or the logic around it in the CPU) set the microPC of final microops to be a sentry value like 0. When the PCState for an ISA which has microcode sees that sentry value, it will know to advance the regular PC and reset the microPC. "Normal" instructions will need to set the next microPC to 0 so that they immediately advance the regular PC. With the specific choice of 0, we could blindly set the microPC to the next microPC and get the right result, but that would mean a macroop could never *purposefully* loop back to its first microop, since that would look like it was ending the instruction. Another option could be 0xffff (microPCs are always 16 bits), but then the logic that detects that scenario would also have to override that value. The difference may be trivial, and it may be worth avoiding the limitation of using 0. Since the CPUs already have a lot of logic in them which figures out what they should do in these various scenarios, and since we're currently calling a virtual function on the StaticInst class, I think (hope) that while this new arrangement will be simpler, it will also be more efficient as well. Gabe
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
