在裸机系统（嵌入式微控制器、无 MMU、无分页）上，哪个更贵？完整的上下文切换（注册保存和恢复）还是函数调用（激活记录分配）？
我知道这高度依赖于调用约定和硬件能力，但我该如何评估呢？
编辑：
为了提供更多上下文，我正在尝试对两种调度方案进行建模。第一个是具有任务之间上下文切换的抢先调度程序。第二个是函数指针运行队列，其中任务是状态机，分为几个可入队的函数调用（入队发生在 IO 事件驱动的基础上）。
在大多数情况下，我可以收集关于我的任务花费多长时间（IO 和 CPU 时间）的良好数据，但我需要一些帮助来确定在我的模型中添加为常量的额外开销成本。
【问题讨论】：
标签： function architecture operating-system overhead context-switch
由于触发上下文切换的系统调用是函数调用，并且可以触发上下文切换的硬件中断是相似的，（并且需要对事件/信号量的调用，以及对调度程序入口点的跳转/调用，发出上下文切换信号），我会说函数调用在 CPU 周期方面会更便宜，除非传递了不合理数量的参数。
这听起来像是一个 XY 问题 - 你为什么要问这个？上下文切换和函数调用几乎是正交的——一个是基于堆栈的机制，另一个则完全选择不同的堆栈。
【讨论】：
您可以通过对比这些技术及其对整体数据移动的实际影响来评估这一点。
例如，在 6502 上，中断推送：程序计数器、X、Y、A 和状态寄存器。那是 6 个字节的实际数据，需要 7 个 CPU 周期。
诚然，6502 是比现代设计简单得多的 CPU，但它是问题的一个基本示例。
现在，一个函数调用可以说是一个跳转子例程，它只是将当前 PC 压入堆栈，然后将 PC 更改到新位置。在 6502 上，一个 JSR 需要 6 个周期。
如果将 JSR 和 BRK（6502 上的软件中断）视为原语，JSR 比 BRK 便宜 1 个周期。这超出了建立调用框架的成本。
大多数上下文切换是自动完成的（通过计时器或其他方式）以模拟多处理。但有些系统使用 CPU 陷阱原语进行系统调用（如 MS-DOS 中的 INT 和旧 Mac OS 中的 TRAP）。所以一个软中断仍然需要建立堆栈帧，就像一个普通的子程序一样。
最后，JSR 可能比任何更高级别的开关机制都便宜，仅仅是因为它非常轻量级。中断机制通常具有子程序所没有的间接机制（这就是为什么它们在系统调用中如此多地使用）。编译器在编译时管理子程序地址。
但这些是评估原始性能时要考虑的因素。
【讨论】：