call - 为什么 CALL 的操作码获取中有 6T 状态而不是 4？

Question

我的问题是为什么 CALL 指令的操作码获取中有 6T 状态，而 8085 微处理器中的其他指令有 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)。

Answer 1

6(取操作码)+ 3 + 3(两次内存读取以读取子程序地址)+ 3 + 3(两次内存写入堆栈)= 18

所以我相信让您感到困惑的是操作码获取的 6 个 T 状态，而不是通常情况下的 4 T 状态。4 T 状态用于获取操作码，就像在任何其他指令获取中一样。 2个T状态用于处理堆栈指针(SP)。因为在堆栈顶部没有存储任何内容。当遇到调用时，程序计数器的当前内容(写入调用的行的地址)被插入堆栈。执行完成后，堆栈的内容必须放回。因此，调用需要两个额外的状态，而不是其他指令获取。