估计软件的内存大小
我正在开发将嵌入到项目的 PROM 芯片中的 Boot。 我的任务是估计软件可能占用的最终内存大小，但我以前从未这样做过。
我搜索了一下，我正在考虑执行以下操作：
- 计算所有变量，这个大小直接等于总大小
- 估计每个函数将需要的代码行数（代码尚未编写）
- 查找每个c指令的asm指令的大约数量
- 总大小=总nb行代码*每个c指令的平均asm指令*32位
我的解决方案很可能是假的，我希望有人能够提供帮助。
I'm working on the development of Boot that will be embedded in a PROM chip for a project.
I was tasked with making an estimation of the final memory size that the software will probably take but I've never done this before.
I searched a bit around and I'm thinking about doing the following:
- Counting all the variables, this size goes directly to the size total
- Estimating a number of line of codes each function will take (the code hasn't been written yet)
- Finding out an approximate number of asm instruction per c instruction
- Total size = Total nb line of codes * avg asm instruction per c instruction * 32bit
My solution could very well be bogus, I hope someone will be able to help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
原则上 - 你是在正确的轨道上：
你需要区分几种类型的内存占用：
堆栈主要受递归、局部变量和函数的影响参数。
动态内存（堆）是显而易见的，而且可能与您无关 - 所以我现在忽略它。
初始化变量很有趣，因为您需要对它们进行两次计数 - 一次用于计算 PROM 上的程序占用空间（类似于代码和常量），一次用于计算 RAM 占用空间。
未初始化的变量显然会进入 RAM，计算大小几乎已经足够了（您还需要考虑对齐和填充。
最难估计的是代码或进入 PROM 的内容，您需要计算常量和局部变量以及代码，代码本身或多或少是你所怀疑的（在添加填充、对齐、函数调用开销、中断向量初始化等之后），但很多东西可以使它比预期大，例如内联函数、库函数（许多看似琐碎的操作涉及这样的功能），铸造等。
On principle - You are on the right track:
You need to distinguish between several types of memory footprint:
Stack is mostly impacted by recursion, local variables and function parameters.
Dynamic memory (heap) is obvious and also probably not relevant to you - so I'll ignore it for now.
Initialised variables are interesting since you need to count them twice - once for the program footprint on the PROM (similar to code and constants) and once for the RAM footprint.
Un-initialised variables obviously go toward the RAM and counting the size is almost good enough (you also need to consider alignment and padding.
The hardest to estimate is code or what goes into PROM, you need to count constants and local variables as well as the code, the code itself is more or less what you suspect (after adding padding, alignment, function call overhead, interrupt vector initialisation etc.) but many things can make it larger than expected, such as inline functions, library functions (many seemingly trivial operations involve such functions), casting etc.
回答这个问题的方法是根据经验或对具有类似功能的现有代码的评估。然而，有许多因素会影响代码大小：
“启动的开发”没有告诉我们任何有关启动过程的要求或功能的信息。这将对代码大小产生最大的影响。作为目标如何发挥作用的一个示例，8 位目标通常具有更高的代码密度，但会为较大数据类型的算术生成更多代码，而在 ARM 目标上，您可以在 Thumb 和 ARM 指令集之间进行选择，代码密度将发生显着变化。
如果您之前没有经验或没有代表性的代码库可供使用，那么我建议您执行一些实验来获取一些可以使用的指标：
构建一个空应用程序 - 如果是 C 或 C++，则只是一个空的 main() 函数;这将为您提供运行时启动的基本固定开销。
如果您使用库代码，这可能会占用大量空间；向您将在最终应用程序中使用的所有库接口添加虚拟调用，这将告诉您库代码将占用多少代码（假设库代码不是内联的）。
此后将取决于功能；您可以实现所需功能的子集，然后估计最终构建可能构成的比例。
关于您的建议，请记住变量不会占用 ROM 中的空间，尽管任何常量初始化器都会占用空间。通常，引导加载程序可以使用所有可用的 RAM，因为应用程序启动将为自身重新建立一个新的运行时环境，从而丢弃引导加载程序环境和变量。
如果您要提供功能和目标的详细信息，您也许可以利用社区的经验来估计所需的资源。例如，我也许可以告诉您（根据经验）支持闪存编程的引导加载程序（通过 UART 使用 XMODEM 协议在使用 ARM 指令集的 ARM7 上加载）将适合 4k 字节，或者添加对通过 SD 卡加载的支持可能会进一步增加 6Kb，例如 USB 虚拟通信端口会进一步增加 4Kb。然而，您的需求可能是独特的，您必须以某种方式自行确定资源负载。
On way of answering the question would be from experience or assessment of existing code with similar functionality. However there will be a number of factors that affect code size:
The "development of Boot" tells us nothing about the requirements or functionality of your boot process. This will have the greatest affect on code size. As an example of how target can make a difference, 8-bit targets typically have greater code density, but generate more code for arithmetic on larger data types, while on say an ARM target where you can select between Thumb and ARM instruction sets, the code density will change significantly.
If you have no prior experience or representative code base to work from, then I suggest you perform a few experiments to get some metrics you can work with:
Build an empty application - just an empty main() function if C or C++; that will give you the basic fixed overhead of the runtime start-up.
If you are using library code, that will probably take a significant amount of space; add dummy calls to all library interfaces you will make use of in the final application, that will tell you how much code will be taken up by library code (assuming the library code is not in-lined).
Thereafter it will depend on functionality; you might implement a subset of the required functionality, and then estimate what proportion of the final build that might constitute.
Regarding your suggestions, remember that variables do not occupy space in ROM, though any constant initialisers will do so. Typically a boot-loader can use all available RAM because the application start-up will re-establish a new runtime environment for itself, discarding the boot-loader environment and variables.
If you were to provide details of functionality and target, you may be able to leverage the experience of the community in estimating the required resources. For example I might be able to tell you (from experience) that a boot-loader with support for Flash programming that loads via a UART using XMODEM protocol on an ARM7 using ARM instruction set will fit in 4k Bytes, or that adding support for loading via SD card may add a further 6Kb, and say USB Virtual Comm Port a further 4Kb. However your requirements are possibly unique and you will have to determine the resource load for yourself somehow.