On Wed, Nov 10, 2010 at 9:42 AM, Ali Saidi <[email protected]> wrote: > On Wed, 10 Nov 2010 09:37:54 -0800, Steve Reinhardt <[email protected]> > wrote: > > > > On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi <[email protected]> wrote: > >> On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt <[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]> 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
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
