嵌入式软件的 Mips 计算
最近（并且多次）客户向我询问运行我们的软件所需的 MIPS。 通常，我们可以通过向客户解释这实际上取决于 cpu/os/hw（我们的软件具有高度可移植性）和/或用例（即我们的软件如何使用）来摆脱这个问题。
但我的最后一个不仅非常固执，而且还提供了固执的充分理由。 :) 他想要一个估算，因为他不确定自己是否有足够的能力来运行我们的软件，因此在此估算之前购买软件是不合逻辑的。 （我们无法提供演示/评估，因为在这个特定平台上运行需要大量的工作。）
现在的问题是：是否有人有在任何硬件上使用任何软件执行此类任务的经验？ 任何现实生活中的例子都会非常有帮助。 我可以选择在许多操作系统和硬件上运行我们的软件。 因此，如果您知道在任何硬件上进行此类估计的任何工具，我就有机会使用它或至少得到一个想法。 据了解，我只知道如何测量 eCosPro OS 上的 CPU 负载。
编辑：
使用探针实际上是一个好主意，假设我可以创建一个控制环境，其中只有我的软件正在运行我可以计数的所有指令，并且我猜探针有一个接口可以做到这一点。 实际上，我有一些不同的硬件调试器，如果有人有经验如何做到这一点，那将非常好，无论如何我明天都会阅读一些文档，希望能在这个方向找到一些东西。
I have been recently (and repeatedly) asked by customers about MIPS needed to run our software. Usually we was able to get rid of this questions by explaining the customer that this is really depend on the cpu/os/hw (our software is highly portable) and/or use case (i.e. how our software is used).
But I have a last one not only very stubborn but in addition provides good reasons to be stubborn. :) He wants an estimate because he is not sure he has enough power to run our software, so buying the software before this estimate is not logical. (We can't provide the demo/evaluation since it will require significant amount of work to run on this specific platform.)
And now the the question: Does somebody have an experience with such task on any piece of hw with any software? Any real life example will be really helpful. I have an option to run our software on many OS and many hardware. So if you know any tool for such estimate on any hardware there is a chance I can use it or at least get an idea. For know I only know how to measure CPU load on eCosPro OS.
Edit:
Using probe is actually a good idea, assuming that i can create a control environment where only my software is running all instruction i can count is mine, and i guess probe has an interface to do it. Actually i have a few different hardware debuggers and if somebody have experience how to do it will be really good, any way I'm going to read some documentation tomorrow and hopefully will find something in this direction.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
好吧，您知道这充满了免责声明和内容。 警告——CPU 速度、内存速度、缓存命中、MMU 页表刷新、总线争用等...（如果是重型嵌入式系统）都会对决策产生重要影响...
话虽如此...我要做的就是这个。 获取一个实时操作系统（跟我一起），也许像 FreeRTOS（免费，真是令人惊讶）或 u/C-OS-II（不免费用于商业用途，也许 3000 美元）。 这些内核允许您对代码进行检测以计算空闲 CPU 周期（空闲任务旋转循环）。
因此，将您的整个应用程序（或客户的应用程序）作为你们同意的板上（例如MPC860板、ARM7板等）上唯一（非空闲）任务来运行。 通过 RTOS 测量板上的 CPU 百分比。 （例如“在以 60 MHz 运行的 Flibber 板上，我们的应用程序使用了 12% 的 CPU。”）如果
他们不给你更多的时间，反之亦然，这听起来对他们来说是一个相当合理的长度。
好处是，一旦您完成了此操作，您可以将工作重新用于其他目标和/或板，也许这些数字将帮助您增加销售额和/或调整/优化您的软件。
祝你好运！
OK you realize that this is fraught with disclaimers & warnings -- CPU speeds, memory speeds, cache hits, MMU page tables flushes, bus contention, etc... (if it's a heavy-duty embedded system) all factor significantly into the decision....
Having said that.... what I would do is this. Get a real-time operating system (stay with me), perhaps something like FreeRTOS (free, what a surprise) or u/C-OS-II (not free for commercial use, maybe $3K). These kernels allow you to instrument the code to count idle CPU cycles (idle task spin loop).
So run your whole application (or the customer's application) as the only (non-idle) task on a board that you guys agree on (e.g. MPC860 board, ARM7 board, etc...). Measure the % CPU on the board via the RTOS. (e.g. "on the Flibber board running at 60 MHz, our application used 12% of the CPU.")
Without them giving you more, or vice versa, that sounds like a pretty reasonable length to go to for them.
The good thing is that once you've done this, you can re-use the work for other targets and/or boards, maybe the figures will help you increase sales and/or tune/optimize your software.
Good luck!
您是否有可以为您提供指令计数的模拟器或调试器探针？ 您甚至不需要为正确的目标平台执行此操作，只需粗略的指令计数即可。
如果其他一切都失败，请在您有权访问的任何平台上运行它，并根据您的 MHz/客户的 MHz 的商来调整运行时间。 这应该可以让您非常粗略地估计客户将体验到什么样的运行时。
Do you have a simulator or debugger probe which can give you a instruction count? You don't even need to do it for the right target platform, just a rough instruction count will do.
If everything else fails, run it on whatever platform you have access to, scale the runtime with the quotient of your-MHz/customer's-MHz. This should give you a very rough estimate of what kind of runtimes the customer will experience.
对于具有操作系统的系统来说，I/S 是一个“弱”指标。
本质上，您要做的就是
I/S is a "weak" metric for a system with an operating system.
In the nitty-gritty, what you have to do is
您需要做的第一件事是提出某种正确操作的标准。
这在很大程度上取决于应用程序的性质 - 您的标准可能包括“必须在 3 毫秒内执行代码 x”，或“延迟必须低于 100 毫秒”。
任何与定量测量无关的标准都会很困难，因为它是主观的。
找到正确操作的标准将使您能够找到代码的关键部分。 请记住，这些可能出现在极端情况下，而不是正常操作中。
如果代码的这些关键部分很小，那么计算目标平台的指令将相对简单。 如果你有模拟器的话可能会更容易。 （根据代码，您可能需要进行模拟以确保它被执行，但如果您有大量代码需要分析，这可能仍然比计算指令更容易）
如果您的关键代码很大，那么你可能需要做一些类似于 JesperE 的建议的事情。 除非您的应用程序针对的是对价格极其敏感的行业，否则客户很可能愿意接受稍微宽松的计算 - 因此高估您的 CPU 需求比低估您的 CPU 需求要好。
我与 JesperE 的建议不同的地方是建议不要关注 MHz，而是目标的实际 MIPS。 例如，在测试平台上编译并执行代码 - 如果您有一个分析器可能会更好。 然后针对客户的目标编译代码，并对生成的可执行文件中的指令数量进行粗略比较。
然后，您可以将此比率以及测试处理器和目标处理器的相对 MIPS 纳入执行时间的计算中。
The first thing that you're going to need to do is to come up with some sort of criteria for correct operation.
This is going to depend very much on the nature of the application - your criteria might include "must execute code x in 3ms", or "must have a latency lower than 100ms".
Any criterion that doesn't relate back to a quantitative measurement is going to be difficult as it will be subjective.
Finding your criteria for correct operation will allow you to find the critical portions of code. Bear in mind that these may be found in corner cases rather than normal operation.
If those critical portions of code are small then counting instructions for your target platform is going to be relatively straightfoward. If you've got a simulator that may be even easier. (depending on the code you may need to do a mock up to ensure that it gets executed, but that will likely still be easier than counting instructions if you've got a big chunk of code to analyse)
If your critical code is large then you might have to do something similar to JesperE's suggestion. Unless your application is targeted at an incredibly price sensitive industry the chances are that the customer will be willing to accept a little slack in the calculations - so better to over estimate than under estimate your cpu requirements.
Where I would differ from JesperE's suggestion is to suggest not concentrating on MHz but rather the actual MIPS of the targets. For example, compile and execute your code on a test platform - if you've got a profiler that may be all the better. Then compile your code for the customer's target and do a rough comparison of the number of instructions in the resultant executable.
You can then incorporate this ratio, along with the relative MIPS of the test and target processors, into the calculation of execution time.
你说你的软件具有高度可移植性，所以我的建议是在处理器架构、处理器指令集和内存/外设总线类型最接近的平台上运行该软件。 测量必须实时运行的最长例程，然后估计它将在其架构上运行多长时间。
You say that your software is highly portable, so my suggestion would be to run the software on the platform that is closest in processor architecture, processor instruction set and memory / peripheral bus type. Measure the longest routine that has to run in realtime and then make an estimate as to how long it will run on their architecture.
大多数现代调试器都使您能够查看所使用的指令，例如； RVDS。 另外，您可以使用处理器模拟器来了解所消耗的指令，而无需在平台上实际运行（如果您的代码是独立的，例如编解码器或加密模块并且不依赖于主板） - 请注意，这将为您提供指令，不是循环。 周期将受到您的主板详细信息的影响（例如等待状态、内存访问等）
Most modern day debuggers give you the capability to view the instructions consumed eg; RVDS. Plus, you can use processor emulators to get a decent idea of instructions consumed without actually running on the platform (if your code is standalone such as a codec or a cryptographic module and doesnt depend on board) - note that this will give you instructions, not cycles. The cycles will be affected by your board details (eg; wait states, memory access etc)
在我使用的两种处理器架构（MSP430F5X 和 AVR32）上，处理器中内置了一个硬件周期计数寄存器。 我通常有一个方案，当处理器不忙时，它被置于低功耗空闲状态，处理器核心暂停。 然后有两个选项可用于计算实际处理器负载。 我可以在周期性计时器函数中设置断点并读取执行的处理器周期数，也可以通过在操作开始和结束时读取此寄存器来检测特定进程。 处理器空闲时间不会出现在周期计数中，因为 CPU 在这段时间内暂停。
您没有指定您的处理器架构，但可能存在此功能。
On two of the processor architectures that I use (MSP430F5X and AVR32) there is a hardware cycle count register built into the processor. I normally have a scheme where, when the processor is not busy it is placed into a low power idle state with the processor core halted. There are then two options for working out the actual processor load. I can either set a breakpoint in a periodic timer function and read the number of processor cycles executed or I can instrument particular processes by reading this register at the start and end of their operation. The processor idle time does not appear in the cycle count as the CPU is halted for this time.
You do not specify your processor architecture but this capability may be present.
RapiTime 声称可以为您的目标提供最坏情况执行时间的概率估计。 我个人没有使用过它，但看过他们的演示...
如果您的目标与客户的目标足够相似，您可能可以对其进行扩展以估计他们平台上的 WCET。 然后他们可以将其与当前系统的“空闲”时间进行比较。
RapiTime claims to can give a probabilistic estimate of worst-case execution time for your target. I've not used it personally, but have seen their presentations...
If your target is similar enough to your customer's you can probably scale it to estimate the WCET on their platform. They can then compare that with the "spare" time their current system has.