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

我的问题是为什么在 8085 微处理器中 CALL 指令的操作码获取中有 6T 状态，而其他指令有 4 个状态。我进行了很多搜索，但没有找到满意的答案。

Here: http://www.edaboard.com/thread201650.html它说这与 CALL 情况下使用的双寻址模式有关。但并没有真正解释为什么 6T 会这样。

任何想法？

EDIT

当我知道 CALL 需要 18 个 T 状态时，就出现了这个问题。

根据我的计算，它应该是：4（用于操作码获取）+ 3 + 3（两次内存读取以读取子例程地址）+ 3 + 3（用于堆栈上的两次内存写入）= 16

因此，在搜索互联网时，我了解到 CALL 情况下的操作码获取部分需要 6T 状态而不是 4。

UPDATE

现在，在阅读评论并重新思考后，我知道 PUSH 通常需要 12 个 T 状态作为指令。在 CALL 的情况下，我们可以忽略 PUSH 的操作码获取部分，因为没有显式的 PUSH 指令，所以现在我们有 8 (12 - 4)。那么，我觉得是因为堆栈指针递减吗？因为即使在推送中，它也应该是 6（内存写入为 3 + 3），但这里是 8 (4 + 4)。

6（操作码获取）+ 3 + 3（两次内存读取读取子程序地址）+ 3 + 3（两次内存写入堆栈）= 18

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