Hi everybody. I'm at the point where interrupts percolate through the various controllers and the memory system and end up as a fault object in the CPU. Now I need to figure out how to actually go through all the motions defined by the ISA to enter an interrupt, and since these are fairly complicated and involve a bunch of memory references, they seem like good candidates to implement through microcode. What I've been planning for these sorts of things from the start was to have a common area in the ROM (which I haven't implemented yet, btw) which you can get to from any PC. Once you've executed all the microops and you're ready to execute real instructions again, you just go to the target PC with a micropc of 0 and start executing. This would be fine, but there needs to be a PC value, which would be arbitrary in this case, which the micropc would live under and would be where the macroop containing the microops to enter the interrupt would come from. This instruction fetch would actually have to produce some legal instruction in order for everything to work, and the tricky part is figuring out where it should come from. Since this might be confusing, Here's a more step by step description of how this all might work. I'll use the syntax A:B for PCs where A is the macropc and B is the micropc
1. Instruction X is executing. 2. An interrupt comes in. 3. Some instruction Y starts executing at micropc y 4. The microops at Y:y manipulate the stack, look things up in tables, etc, to transition into the interrupt. 5. A microop in Y:y changes the NPC to Z so that when the next instruction is fetched, the interrupt handler will start 6. The Y:y code ends. 7. Execution starts up with Z:0 You may wonder why Y matters, but this is because X may not exist in the CPU any more, may cause an fault on fetch, etc., and it doesn't yet know what Z is. The decode mechanism as it stands needs a macroop to fetch microops out of, and the existance of a ROM or the fact that the microops are constant regardless of the macroop is an implementation detail the microcode system doesn't know about. Relatedly, you may wonder why Y starts executing at y instead of, for instance, 0. This is in case you've got a faulting instruction (not a fetch) and want to enter the fault handler in the same way. In this case, you would do the following. 1. Instruction X:x faults (say a page fault). 2. The fault object changes the micropc to y. 3. Microops start executing from X:y (which is the same as Y:y since they're coming from the ROM) 4. At some point, a microop changes the NPC to Z. 5. The code in X:y ends. 6. Execution starts up with Z:0. The handy property here is that Y isn't needed at all because you know you have a real live X to work out of. This problem also arises if you have a fault when fetching an instruction. I'm going to think about how this might work, and I'd appreciate if anyone has any comments or suggestions. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
