嵌入式软件的 Mips 计算答案

【问题标题】：Mips calculation for embedded software嵌入式软件的 Mips 计算
【发布时间】：2008-11-17 21:06:59
【问题描述】：

客户最近（并反复）向我询问运行我们的软件所需的 MIPS。通常我们可以通过向客户解释这实际上取决于 cpu/os/hw（我们的软件是高度可移植的）和/或用例（即我们的软件是如何使用的）来摆脱这个问题。

但我有最后一个，不仅非常固执，而且还提供了固执的充分理由。 :) 他想要估价，因为他不确定自己是否有足够的能力运行我们的软件，所以在估价之前购买软件是不合逻辑的。（我们无法提供演示/评估，因为它需要在这个特定平台上运行大量工作。）

现在的问题是：有人在使用任何软件的任何硬件上都有过此类任务的经验吗？任何现实生活中的例子都会非常有帮助。我可以选择在许多操作系统和许多硬件上运行我们的软件。因此，如果您知道在任何硬件上进行此类估算的任何工具，那么我就有机会使用它或至少得到一个想法。要知道我只知道如何测量eCosPro OS 上的 CPU 负载。

编辑：

使用探针实际上是一个好主意，假设我可以创建一个控制环境，其中只有我的软件在运行我可以计算的所有指令都是我的，我猜探针有一个接口可以做到这一点。实际上，我有一些不同的硬件调试器，如果有人有经验如何做这将非常好，无论如何我明天将阅读一些文档，并希望能在这个方向找到一些东西。

【问题讨论】：

标签： c performance embedded measurement

【解决方案1】：

好的，您意识到这充满了免责声明和警告——CPU 速度、内存速度、缓存命中、MMU 页表刷新、总线争用等...（如果它是重型嵌入式系统）所有因素都非常重要进入决定....

话虽如此....我要做的就是这个。获得一个实时操作系统（留在我身边），也许像 FreeRTOS（免费，真是惊喜）或 u/C-OS-II（不是免费用于商业用途，可能是 3000 美元）。这些内核允许您检测代码以计算空闲 CPU 周期（空闲任务自旋循环）。

因此，在你们同意的板上（例如 MPC860 板、ARM7 板等）上运行您的整个应用程序（或客户的应用程序）作为唯一（非空闲）任务。通过 RTOS 测量板上的 CPU 百分比。（例如“在以 60 MHz 运行的 Flibber 板上，我们的应用程序使用了 12% 的 CPU。”）

如果他们不给你更多，反之亦然，这听起来对他们来说是一个相当合理的长度。

好消息是，一旦您完成了这项工作，您就可以将工作重新用于其他目标和/或电路板，也许这些数字将帮助您增加销售额和/或调整/优化您的软件。

祝你好运！

【讨论】：

这似乎是一个合理的近似值。
这是我在阅读 JesperE 帖子之前计划做的方法。尽管 cpu 使用情况对我来说听起来更相关的信息，但客户想要 MIPS，我会尝试看看是否可以从 ICE 获取 MIPS 信息。
Ilya - 抱歉，我没有完全“关闭循环”——假设在 60 MHz 时，您的 CPU 提供 ~50 MIPS....所以如果您的程序使用 10% 的 CPU ( 90% 空闲），它正在使用大约 10% 的 50 MIPS = 5 MIPS。
当然，我明白这一点。在我看来，探测方法更通用，例如，如果我能找到从劳特巴赫获取 mips 的方法，我将能够在任何平台上获取 mips 信息在每个操作系统上都有ice接口，无需额外编码（我们支持大量操作系统），

【解决方案2】：

您是否有可以为您提供指令计数的模拟器或调试器探针？您甚至不需要针对正确的目标平台执行此操作，只需粗略的指令计数即可。

如果一切都失败了，请在您可以访问的任何平台上运行它，使用您的-MHz/客户的-MHz 的商来扩展运行时。这应该让您非常粗略估计客户将体验到什么样的运行时。

【讨论】：

好主意，你知道任何探针可以做到吗？我的平台上的估计会让客户满意。
我没有太多使用不同调试器探针的经验，很遗憾，我对你可以用它们做什么只有粗略的了解。
谢谢，我会在收到结果后在这里发布结果:)

【解决方案3】：

I/S 是具有操作系统的系统的“弱”指标。

在本质上，你要做的是

找出最坏情况下的指令路径并计算执行所需的周期数（这意味着阅读该 CPU 的程序集并查看告诉您周期数的 CPU 手册）。
现在找出您的实时约束。
然后将#1 用于最坏情况循环。向上/向下调整 CPU，直到它适合实时约束。
添加一个软糖因子。

【讨论】：

这是一条很长的路…… :) 软件又大又复杂。

【解决方案4】：

您需要做的第一件事是提出一些正确操作的标准。这在很大程度上取决于应用程序的性质——您的标准可能包括“必须在 3 毫秒内执行代码 x”，或“必须具有低于 100 毫秒的延迟”。任何与定量测量无关的标准都将是困难的，因为它是主观的。

找到正确操作的标准将使您能够找到代码的关键部分。请记住，这些可能出现在极端情况下，而不是正常操作中。

如果代码的这些关键部分很小，那么为您的目标平台计算指令将相对简单。如果你有一个模拟器可能会更容易。（取决于你可能需要做一个模拟以确保它被执行的代码，但如果你有大量代码要分析，这可能仍然比计算指令更容易）

如果您的关键代码很大，那么您可能需要执行类似于 JesperE 的建议的操作。除非您的应用程序针对的是对价格极其敏感的行业，否则客户可能会愿意接受计算中的一点松懈——因此，高估比低估您的 CPU 需求要好。

我与 JesperE 建议的不同之处在于建议不要专注于 MHz，而是关注目标的实际 MIPS。例如，在测试平台上编译和执行你的代码——如果你有一个分析器可能会更好。然后为客户的目标编译您的代码，并对生成的可执行文件中的指令数量进行粗略比较。然后，您可以将此比率与测试和目标处理器的相对 MIPS 一起纳入执行时间的计算中。

【讨论】：

【解决方案5】：

你说你的软件是高度可移植的，所以我的建议是在处理器架构、处理器指令集和内存/外围总线类型最接近的平台上运行软件。测量必须实时运行的最长例程，然后估计它将在其架构上运行多长时间。

【讨论】：

问题是如何测量......我想到了测量的想法:)
1.当您进入和退出关键程序时切换一个引脚。使用引脚上的示波器测量时间。 2.设置你的编译器输出汇编文件，统计每个例程的代码行数，粗略猜测指令数
这不太可能，我的代码库比一般嵌入式操作系统代码库要大。找到最长的例程是不够的，找到最长的执行路径更合适，但在技术上有点困难。

【解决方案6】：

大多数现代调试器都让您能够查看所使用的指令，例如； RVDS。另外，您可以使用处理器仿真器来了解所消耗的指令，而无需在平台上实际运行（如果您的代码是独立的，例如编解码器或加密模块并且不依赖于板子） - 请注意，这将为您提供说明，不是循环。周期将受到您的板详细信息（例如；等待状态、内存访问等）的影响

【讨论】：

【解决方案7】：

在我使用的两种处理器架构（MSP430F5X 和 AVR32）上，处理器中内置了一个硬件周期计数寄存器。我通常有一个方案，当处理器不忙时，它被置于低功耗空闲状态，处理器内核停止。然后有两个选项可以计算实际的处理器负载。我可以在周期性定时器函数中设置断点并读取执行的处理器周期数，也可以通过在操作开始和结束时读取此寄存器来检测特定进程。处理器空闲时间不会出现在循环计数中，因为此时 CPU 会暂停。

您没有指定您的处理器架构，但可能存在此功能。

【讨论】：

【解决方案8】：

RapiTime 声称可以为您的目标提供最坏情况执行时间的概率估计。我个人没用过，但是看过他们的介绍...

如果您的目标与您的客户的目标足够相似，您可能可以对其进行缩放以估计其平台上的 WCET。然后，他们可以将其与当前系统的“空闲”时间进行比较。

【讨论】：