On 11/10/10 10:12, Ali Saidi wrote: > > On Wed, 10 Nov 2010 09:49:19 -0800, Steve Reinhardt <[email protected]> > wrote: > >> >> >> On Wed, Nov 10, 2010 at 9:42 AM, Ali Saidi <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, 10 Nov 2010 09:37:54 -0800, Steve Reinhardt >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt >> <[email protected] <mailto:[email protected]>> wrote: >> >> Pardon my naivete, but what does the "delayed commit" >> flag do? >> >> On Mon, Nov 8, 2010 at 11:58 AM, Ali Saidi >> <[email protected] <mailto:[email protected]>> wrote: >> >> changeset ba11187e2582 in /z/repo/m5 >> details: >> http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582 >> description: >> ARM: Make all ARM uops delayed commit. >> >> Really, it should be all non-lastuop uops delayed commit, >> but it tells the cpu model that it the uop can't be >> committed until all uops in the op are complete. In terms >> of the simple cpu it prevents an interrupt from occurring >> mid-uop. >> >> >> As you imply, why isn't this the default behavior? I can see >> having a special flag for the occasional case where a >> macroinstruction is interruptible other than at the end of >> the instruction, but this seems backwards. >> >> Steve >> >> The uops themselves don't know where they are in a macro-inst >> (the last one isn't delayed commit), so something needs to tell >> them. In this case the uops are repurposed from other non-uop >> instructions. >> >> I don't quite follow... why isn't it the case that (1) if I'm >> processing a uop and not a non-microcoded instruction and (2) the uop >> is not flagged as the last one then the CPU model knows not to take >> an interrupt? Is #1 that hard to determine? >> >> Steve >> > You'll have to ask Gabe about that one. He is the one that came up > with that plan some four years ago. > > Ali > > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev
Actually I think that was largely informed by you, Steve :-). Basically there are macroops that can be (or at least should be able to be) interrupted at intermediate points, specifically string instructions. Initially delayed commit was intended to be a flag that made instructions build up in commit until an instruction was ready that didn't have it set and was therefore a commit point. Then all the built up instructions would commit. That would have been hard, so instead we (I) wrote the macroops so that if something bad happened because of execution, ie. a page fault, the fact that they stopped midstride would still leave architectural state intact and make it look like the instruction was atomic. This was generally not that big a deal, but sometimes it was a real pain. This still left interrupts, so now the delayedCommit flag basically just disallows interrupts immediately following certain instructions, generally in the middle of macroops. There are also individual instructions in x86 that can't be immediately followed by an interrupt and have what's called an interrupt shadow. I forget what they all are, but one I think is when you pop the stack selector off the stack, or maybe just move a new selector into it. Interrupts are disabled for one instruction to allow you to update the stack pointer so that if an interrupt comes along, there's a valid stack for it to land on. I imagine someone somewhere had this all planned out and then discovered interrupts weren't as transparent as they were supposed to be. "I know!" they said, and made everybody's life a little harder for the next few decades. In any case, I intend to implement those by setting delayedCommit on the last microop of a macroop or even a whole instruction, depending on where it's needed. The delayedCommit flag is usually redundant, but it does provide a necessary extra degree of freedom. It sounds like you might be saying there should be a default behavior (no interrupts mid macroop, interrupts otherwise) and let the flag complement that behavior. I think as far as how much work the simulator would have to do I think it would be about the same, and the parts executing the instruction would be more complicated since they would have to figure out what the default behavior was and then conditionally complement it instead of just doing what the flag says. I like what we've got, although the name is historical and not that accurate any more. Gabe
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
