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