我正在为一个项目开发将嵌入 PROM 芯片中的 Boot。 我的任务是估计软件可能占用的最终内存大小，但我以前从未这样做过。
我搜索了一下，我正在考虑执行以下操作：
我的解决方案很可能是假的，我希望有人能够提供帮助。
【问题讨论】：
标签： memory-management embedded estimation sizing
原则上 - 你在正确的轨道上：
你需要区分几种类型的内存占用：
堆栈主要受递归、局部变量和函数参数的影响。
动态内存（堆）很明显，也可能与您无关 - 所以我现在将忽略它。
初始化变量很有趣，因为您需要计算它们两次 - 一次用于 PROM 上的程序占用空间（类似于代码和常量），一次用于 RAM 占用空间。
未初始化的变量显然会进入 RAM，计算大小几乎就足够了（您还需要考虑对齐和填充。
最难估计的是代码或进入 PROM 的内容，您需要计算常量和局部变量以及代码，代码本身或多或少是您所怀疑的（在添加填充、对齐、函数调用开销之后，中断向量初始化等），但很多事情可以使它比预期的要大，例如内联函数、库函数（许多看似微不足道的操作都涉及此类函数）、强制转换等。
【讨论】：
回答问题的方式将来自经验或对具有类似功能的现有代码的评估。然而，影响代码大小的因素有很多：
“Boot 的开发”没有告诉我们有关引导过程的要求或功能的任何信息。这将对代码大小产生最大的影响。作为目标如何发挥作用的示例，8 位目标通常具有更高的代码密度，但会生成更多代码用于更大数据类型的算术运算，而在 ARM 目标中，您可以在 Thumb 和 ARM 指令集之间进行选择，代码密度将发生显着变化。
如果您之前没有经验或有代表性的代码库可供使用，那么我建议您进行一些实验以获得一些可以使用的指标：
构建一个空的应用程序 - 如果是 C 或 C++，则只是一个空的 main() 函数；这将为您提供运行时启动的基本固定开销。
如果您使用库代码，那可能会占用大量空间；为您将在最终应用程序中使用的所有库接口添加虚拟调用，这将告诉您库代码将占用多少代码（假设库代码未内联）。
此后将取决于功能；您可能会实现所需功能的子集，然后估计可能构成的最终构建的比例。
关于您的建议，请记住变量不会占用 ROM 中的空间，尽管任何常量初始化程序都会这样做。通常，引导加载程序可以使用所有可用的 RAM，因为应用程序启动将为自己重新建立一个新的运行时环境，丢弃引导加载程序环境和变量。
如果您要提供功能和目标的详细信息，您可以利用社区的经验来估算所需资源。例如，我可能会告诉您（从经验），支持 Flash 编程的引导加载程序（通过 UART 使用 XMODEM 协议在使用 ARM 指令集的 ARM7 上加载）将适合 4k 字节，或者添加对通过 SD 卡加载的支持可能会再增加 6Kb，例如 USB 虚拟通信端口会再增加 4Kb。但是，您的需求可能是独一无二的，您必须以某种方式自行确定资源负载。
【讨论】：