什么更昂贵？上下文切换还是函数调用？

Question

在裸机系统（嵌入式微控制器，没有MMU，也没有分页）中，什么更加昂贵？是完整的上下文切换（寄存器保存和恢复），还是函数调用（激活记录分配）？

我知道这高度依赖于调用约定和硬件能力，但我该如何评估这个问题呢？

编辑：

为了提供更多背景信息，我正在尝试建模两个调度方案。第一个是抢占式调度程序，在任务之间进行上下文切换。第二个是函数指针运行队列，其中任务是状态机，分成几个可排队的函数调用（其中排队基于IO事件驱动）。

在大多数情况下，我可以收集有关任务所需时间的良好数据（包括IO和CPU时间），但我需要帮助确定要添加到我的模型中的额外开销成本。

- Jon

---

你是否正在尝试执行一个特定的活动，而想知道应该使用哪个概念？ - nj-ath

@darknight - 在上面添加了新注释 - Jon

Answer 1

由于触发上下文切换的系统调用是函数调用，而可以触发上下文切换的硬件中断类似（并需要调用事件/信号量以及跳转/调用到调度程序入口来发出上下文切换信号），我认为在传递了不合理数量的参数之前，函数调用在 CPU 周期方面会更加便宜。

这似乎是一个 XY 问题——你为什么要问这个？ 上下文切换和函数调用几乎是正交的——一个基于堆栈的机制，另一个则完全选择了不同的堆栈。

- Martin James

---

在原始帖子中添加了新的评论。 - Jon

Answer 2

你可以通过对比技术及其对整体数据移动的实际影响来评估这个问题。

例如，在6502上，中断会推送：程序计数器、X、Y、A和状态寄存器。这是6个字节的实际数据，并需要7个CPU周期。

当然，6502比现代设计要简单得多，但它是问题的基本示例。

现在，函数调用可以说只是一个跳转子程序，它只是将当前PC推入堆栈，然后将PC更改为新位置。在6502上，JSR的成本为6个周期。

如果您将JSR和BRK（6502上的软件中断）视为原语，则JSR比BRK便宜1个周期。这不包括建立调用帧的成本。

大多数上下文切换都是自动完成的（通过定时器或其他方式）以模拟多处理。但是，一些系统使用CPU的陷阱原语进行系统调用（例如MS-DOS中的INT和旧Mac OS中的TRAP）。因此，软中断仍然必须建立堆栈帧，就像普通子例程一样。

最终，JSR 可能比任何更高级别的开关机制都要便宜，因为它非常轻量级。中断机制通常具有间接机制（这就是为什么它们在系统调用中被广泛使用）而子程序没有。编译器在编译时管理子程序地址。

但这些是要考虑的因素，以评估原始性能。

- Will Hartung

---

我不太明白。我认为这个问题试图比较不同的事物。方法调用最终归结为跳转指令（加上推送/弹出一些值和改变PC）（是的，你在你的答案中提到了这一点）。另一方面，上下文切换可以随时发生，因为根本没有任何原因。它们是两个不同的东西。 - TheLostMind

在原帖中添加了新的注释 - Jon