使用修改后的返回地址进行 CALL

在 x64 程序集中处理 CALL 的最佳方法是什么，它应该返回到稍微偏移的返回地址？主要涉及效率/执行速度。我将简要解释一下我正在尝试做什么。

背景

我有一种自定义的解释型可视脚本语言，可以编译为本机代码。这种语言具有内置的基于堆栈的协程，以前它们仍然是半解释的（使用单独的堆栈类来存储协程数据）。我正在将其完全本地化，因此仅使用 RSP。

这些协程的一部分是嵌套屈服的能力，这意味着如果协程调用另一个屈服方法，该方法可以在内部屈服以挂起整个调用。该信息通过存储在寄存器中的“YieldState”结构进行处理。这意味着，对于新的完全本地化变体，我们可以使用调用指令从协程中调用生成方法：

call      12345; // [rip+12345] => yieldingMethod

至少在理论上是这样。由于我们的协程是基于堆栈的，因此我们将局部变量简单地存储在堆栈上，而不是像无堆栈协程那样存储在某种类中。这需要通过另一种方法来处理清理（如果协程在完成之前被破坏），我将其称为“中断处理程序”。在我的实际用例中，调用这种中断处理程序很常见，但也不过分。所以我的目标是提供比异常处理程序更快的东西（通常需要对框架进行一些全局查找），但不需要为每个调用显式设置此地址。所以我所做的就是在调用和返回地址之间嵌入中断处理程序地址 - 因为对于旧版本的代码，我们必须手动加载返回，这不是问题：

lea rcx,[rip+25]; // 25 is the assumed byte-size up until the return address
mov rdx,rbx;      // load non-native call stack
call prepareMethodYielding; // stores return-address on stack
jmp 12345;        // actually call our "yieldingMethod"
mov r15,interruptAddress;

最后一条指令永远不会被执行——我们保留返回地址来实际跳过它。我们在这里只有它能够查找中断处理程序。给定一个恢复地址，我们只需将指针减 8，就得到了恢复中断的地址。在我们的例子中，“mov r15”只是为了让我们能够正确反汇编代码；我们可以单独嵌入地址，但这会使任何外部反汇编程序感到困惑。

实际问题

现在在新版本中，没有“prepareMethodYielding”，而只有一个调用 - 至少是最佳的。但“调用”本身不允许我们修改返回地址，所以这里我面临几个选项，我想知道哪一个是最好的。

选项 A - lea + push + jmp

我们的第一个选择是模拟“调用”，但手动推送返回地址：

lea         rax,[rip+10h]
push        rax
jmp         A6 // yieldingMethod

这需要 3 条指令，但不需要访问内存。

选项 B - 从内存中推送

我们可以通过将返回地址存储在常量内存的某个区域来减少选项的数量：

push        qword ptr[rip+1234] // return-address stored here
jmp         A6                  // yieldingMethod

现在我们只需要一次推送，不需要中间寄存器，尽管现在我们需要访问内存，这可能在数据部分更远。

选项 C - 修改被调用函数中的返回地址

我看到的另一个选择是调整被调用方法内的调用生成的返回地址。这里的所有这些方法都是使用我自己的调用约定编译的，因此它们不遵守 x64 或任何其他。

// caller
call     A6                 // yielding method

// callee, first instruction
add      qword ptr[rsp],10  // size of interrupt-embedding is always the same

这也只是一条指令，具有较小的编码。尽管仅从设计角度来看，我不太喜欢它，因为它将有关被调用者嵌入到调用者中的信息耦合在一起 - 不过，如果这是最有效的变体，我可能仍然会选择它。

选项 D - 根本不修改返回地址

我们的最后一个选择是根本不修改返回地址，而是更改查找和返回的处理方式。

call      12345;                // yieldingMethod
mov       r15,interruptAddress; // is actually executed now (but value is not used)

因此，在这里，我们将更改查找中断地址的位置（因为返回地址现在指向假指令的前面，而不是后面）。然后，从调用返回后，我们将执行 movabs 指令，但丢弃加载的值。这里的好处是整体代码大小是最小的，因为我们不需要添加任何尚不存在的附加指令。但是，我们正在执行 10 字节 mov 指令，这可能比其他一些变体慢。这在某种程度上取决于 CPU 正在做什么——如果它已经解码了假指令，即使它没有直接到达它，最好的办法就是执行它，而不是修改返回地址。同样的事情，如果 CPU 能够以某种方式检测到指令没有效果，因为它的值永远不会被读取，在寄存器重命名期间，那么它实际上可以是免费的 - atm，我正在使用一个未使用的寄存器，以区分我自己的汇编器；但我想，使用很快就会被覆盖的寄存器可能是有意义的。尽管我不确定这里实际会发生什么。

结论

那么，这 4 个选项中哪一个对您来说最有效？我也对其他想法持开放态度，尽管协程如何完成的总体设计已经完成并且功能齐全，因此像使用 IIRC 某些协程使用的基于状态机的方法之类的方法在这里并不是真正的选择。