Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
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 [2] 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. Ali Links: -- [1] mailto:ali.sa...@arm.com [2] http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi sa...@umich.edu wrote: On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt ste...@gmail.com wrote: Pardon my naivete, but what does the delayed commit flag do? On Mon, Nov 8, 2010 at 11:58 AM, Ali Saidi ali.sa...@arm.com 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
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 [4] 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. Ali Links: -- [1] mailto:sa...@umich.edu [2] mailto:ste...@gmail.com [3] mailto:ali.sa...@arm.com [4] http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
On Wed, Nov 10, 2010 at 9:42 AM, Ali Saidi sa...@umich.edu wrote: On Wed, 10 Nov 2010 09:37:54 -0800, Steve Reinhardt ste...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi sa...@umich.edu wrote: On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt ste...@gmail.com wrote: Pardon my naivete, but what does the delayed commit flag do? On Mon, Nov 8, 2010 at 11:58 AM, Ali Saidi ali.sa...@arm.com 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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
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:sa...@umich.edu [2] mailto:ste...@gmail.com [3] mailto:sa...@umich.edu [4] mailto:ste...@gmail.com [5] mailto:ali.sa...@arm.com [6] http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
On 11/10/10 10:12, Ali Saidi wrote: On Wed, 10 Nov 2010 09:49:19 -0800, Steve Reinhardt ste...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:42 AM, Ali Saidi sa...@umich.edu mailto:sa...@umich.edu wrote: On Wed, 10 Nov 2010 09:37:54 -0800, Steve Reinhardt ste...@gmail.com mailto:ste...@gmail.com wrote: On Wed, Nov 10, 2010 at 9:31 AM, Ali Saidi sa...@umich.edu mailto:sa...@umich.edu wrote: On Wed, 10 Nov 2010 08:01:37 -0800, Steve Reinhardt ste...@gmail.com mailto:ste...@gmail.com wrote: Pardon my naivete, but what does the delayed commit flag do? On Mon, Nov 8, 2010 at 11:58 AM, Ali Saidi ali.sa...@arm.com mailto:ali.sa...@arm.com 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 m5-dev@m5sim.org 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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: ARM: Make all ARM uops delayed commit.
changeset ba11187e2582 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=ba11187e2582
description:
ARM: Make all ARM uops delayed commit.
diffstat:
src/arch/arm/insts/macromem.hh | 6 --
src/arch/arm/isa/templates/mem.isa | 19 +++
src/cpu/static_inst.hh | 2 ++
3 files changed, 21 insertions(+), 6 deletions(-)
diffs (154 lines):
diff -r ee4ac00d0774 -r ba11187e2582 src/arch/arm/insts/macromem.hh
--- a/src/arch/arm/insts/macromem.hhMon Nov 08 13:58:22 2010 -0600
+++ b/src/arch/arm/insts/macromem.hhMon Nov 08 13:58:22 2010 -0600
@@ -73,12 +73,6 @@
public:
void
-setDelayedCommit()
-{
-flags[IsDelayedCommit] = true;
-}
-
-void
advancePC(PCState pcState) const
{
if (flags[IsLastMicroop]) {
diff -r ee4ac00d0774 -r ba11187e2582 src/arch/arm/isa/templates/mem.isa
--- a/src/arch/arm/isa/templates/mem.isaMon Nov 08 13:58:22 2010 -0600
+++ b/src/arch/arm/isa/templates/mem.isaMon Nov 08 13:58:22 2010 -0600
@@ -917,6 +917,7 @@
assert(numMicroops = 2);
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _base, _mode, _wb);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -934,6 +935,7 @@
assert(numMicroops = 2);
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _regMode, _mode, _wb);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -963,6 +965,7 @@
assert(numMicroops = 2);
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _dest, _dest2, _base, _add, _imm);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -984,6 +987,7 @@
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _result, _dest, _dest2,
_base, _add, _imm);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -1001,6 +1005,7 @@
assert(numMicroops = 2);
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _dest, _base, _add, _imm);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -1021,6 +1026,7 @@
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _result, _dest,
_base, _add, _imm);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -1043,6 +1049,7 @@
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _dest, _dest2, _base, _add,
_shiftAmt, _shiftType, _index);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -1064,6 +1071,7 @@
uops = new StaticInstPtr[numMicroops];
uops[0] = new %(acc_name)s(machInst, _dest, _base, _add,
_shiftAmt, _shiftType, _index);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
#endif
@@ -1087,14 +1095,17 @@
if ((_dest == _index) || (_dest2 == _index)) {
IntRegIndex wbIndexReg = INTREG_UREG0;
uops[0] = new MicroUopRegMov(machInst, INTREG_UREG0, _index);
+uops[0]-setDelayedCommit();
uops[1] = new %(acc_name)s(machInst, _dest, _dest2, _base, _add,
_shiftAmt, _shiftType, _index);
+uops[1]-setDelayedCommit();
uops[2] = new %(wb_decl)s;
uops[2]-setLastMicroop();
} else {
IntRegIndex wbIndexReg = index;
uops[0] = new %(acc_name)s(machInst, _dest, _dest2, _base, _add,
_shiftAmt, _shiftType, _index);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
uops[1]-setLastMicroop();
}
@@ -1119,20 +1130,25 @@
IntRegIndex wbIndexReg = index;
uops[0] = new %(acc_name)s(machInst, INTREG_UREG0, _base, _add,
_shiftAmt, _shiftType, _index);
+uops[0]-setDelayedCommit();
uops[1] = new %(wb_decl)s;
+uops[1]-setDelayedCommit();
uops[2] = new MicroUopRegMov(machInst, INTREG_PC, INTREG_UREG0);
uops[2]-setLastMicroop();
} else if(_dest == _index) {
IntRegIndex wbIndexReg = INTREG_UREG0;
uops[0] = new MicroUopRegMov(machInst, INTREG_UREG0, _index);
+
