为什么在 CALL 的操作码获取中有 6T 个状态而不是 4 个？
Why are there 6T states in opcode fetch of CALL instead of 4?
我的问题是为什么8085微处理器在CALL指令的操作码取操作码中有6T状态，而其他指令有4个状态。我搜索了很多，但没有找到满意的答案。
此处：http://www.edaboard.com/thread201650.html它说它与在 CALL 情况下使用的双寻址模式有关。但并没有真正解释为什么 6T 声明。
有什么想法吗？
编辑
当我知道 CALL 需要 18 个 T 状态时，这个问题就出现了。
根据我的计算应该是：4（取操作码）+ 3 + 3（两次内存读取读取子程序地址）+ 3 + 3（两次内存写入堆栈）= 16
所以，在互联网上搜索我了解到，在 CALL 的情况下，操作码获取部分需要 6T 个状态而不是 4 个。
更新
现在看了评论再想，才知道PUSH一条指令一般需要12个T-states。在 CALL 的情况下，我们可以忽略 PUSH 的操作码获取部分，因为没有明确的 PUSH 指令，所以现在我们有 8 (12 - 4)。所以，我觉得是因为堆栈指针的减少吗？因为即使在 push 中它也应该是 6（内存写入是 3 + 3），但这里是 8（4 + 4）。
4个T状态用于获取操作码； 2 个 T 状态用于递减堆栈指针 (SP)。因为在堆栈顶部没有存储任何内容。
6(opcode fetch) + 3 + 3 (两次内存读取读取子程序地址) + 3 + 3 (两次内存写入堆栈) = 18
所以我相信让您感到困惑的是操作码获取的 6 个 T 状态，而不是通常情况下的 4 个 T 状态。4 个 T 状态用于获取操作码，就像在任何其他指令获取中一样。 2 个T 状态用于处理堆栈指针(SP)。因为在堆栈顶部没有任何内容 stored.When 遇到调用，程序计数器的当前内容（写入调用的行的地址）被推入堆栈。执行完成后，堆栈的内容必须放回原处。因此，该调用比其他指令提取需要两个额外的状态。
我的问题是为什么8085微处理器在CALL指令的操作码取操作码中有6T状态，而其他指令有4个状态。我搜索了很多，但没有找到满意的答案。
此处：http://www.edaboard.com/thread201650.html它说它与在 CALL 情况下使用的双寻址模式有关。但并没有真正解释为什么 6T 声明。
有什么想法吗？
编辑
当我知道 CALL 需要 18 个 T 状态时，这个问题就出现了。
根据我的计算应该是：4（取操作码）+ 3 + 3（两次内存读取读取子程序地址）+ 3 + 3（两次内存写入堆栈）= 16
所以，在互联网上搜索我了解到，在 CALL 的情况下，操作码获取部分需要 6T 个状态而不是 4 个。
更新
现在看了评论再想，才知道PUSH一条指令一般需要12个T-states。在 CALL 的情况下，我们可以忽略 PUSH 的操作码获取部分，因为没有明确的 PUSH 指令，所以现在我们有 8 (12 - 4)。所以，我觉得是因为堆栈指针的减少吗？因为即使在 push 中它也应该是 6（内存写入是 3 + 3），但这里是 8（4 + 4）。
4个T状态用于获取操作码； 2 个 T 状态用于递减堆栈指针 (SP)。因为在堆栈顶部没有存储任何内容。
6(opcode fetch) + 3 + 3 (两次内存读取读取子程序地址) + 3 + 3 (两次内存写入堆栈) = 18
所以我相信让您感到困惑的是操作码获取的 6 个 T 状态，而不是通常情况下的 4 个 T 状态。4 个 T 状态用于获取操作码，就像在任何其他指令获取中一样。 2 个T 状态用于处理堆栈指针(SP)。因为在堆栈顶部没有任何内容 stored.When 遇到调用，程序计数器的当前内容（写入调用的行的地址）被推入堆栈。执行完成后，堆栈的内容必须放回原处。因此，该调用比其他指令提取需要两个额外的状态。