On Wed, 10 Nov 2010 09:49:19 -0800, Steve Reinhardt wrote:
On Wed, Nov 10, 2010 at 9:42 AM, Ali Saidi wrote: On Wed, 10 Nov 2010 09:37:54 -0800, Steve Reinhardt wrote: On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi wrote: On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt wrote: Pardon my naivete, but what does the "delayed commit" flag do? On Mon, Nov 8, 2010 at 11:58 AM, Ali Saidi wrote: changeset ba11187e2582 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582 [6] 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 Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] mailto:[email protected] [4] mailto:[email protected] [5] mailto:[email protected] [6] http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
