Embedded 针对代码大小优化的Newlib

在对内存非常敏感的嵌入式应用程序中，我注意到一些newlib函数使用了大量堆栈空间。通过查看newlib的源代码，特别是本例中的memmem.c，我注意到了两个定义：preference_SIZE_OVER_SPEED和OPTIMIZE_SIZE_uuu，这两个定义可以大大减少内存使用。 据我所知，在编译newlib以使用“针对大小优化”库时，应该定义这些。由于我使用的是cortex-M3微控制器，是否有任何ARM工具链使用“尺寸优化”新库或提供使用它的选项，或者我应该尝试自己构建它。

---

此外，在构建newlib时，我应该同时构建GCC还是只构建库并将其与当前的工具链一起使用。目前我正在使用CoIDE及其提供的工具链。

您只需要构建库，而不需要构建编译器

不过，我希望任何大小优化都与代码大小有关，而不是与堆栈大小有关。只有当自动变量的大小或数量减少时，堆栈大小才会减少，这通常是由所需的功能而不是算法的优化决定的

---

虽然通常涉及大量数据移动的高级操作确实可以通过使用更多内存来加速，但我想说的是，在C标准库的级别上，这样的机会是最小的，因此“更喜欢大小而不是速度”都是关于代码大小而不是数据内存使用。

您使用的是memmem，它不是标准函数。这是glibc中的GNU扩展。您实际运行的代码是str two-way.h。我没有研究它，但它说这是一个类似于Boyer Moore的次线性字符串搜索，并将你引向维基百科关于Boyer Moore的文章。当然，这会有一些内存开销

---

因为它甚至不是一个标准函数，如果您不喜欢它，就没有理由使用newlib的实现。只需使用您自己的子字符串搜索功能。如果您知道二次时间足够好，只需在您自己的代码中使用mem.c中的5行循环即可。您可能需要检查memcmp是否在未对齐的负载上做了正确的事情（如果您的体系结构支持的话）。如果没有，手动嵌套循环可能比调用memcmp更快。

我实际上按照您的建议做了，使用了memmem.c中的短版本代码，但这让我想知道，使用针对大小的优化标志构建newlib是否还有其他好处。我还查看了uClibc的memmem的源代码，它根本不使用memcmp。我并不真正关心性能，因为我只在应用程序的初始化阶段使用memmem，但正如我所说的，我还想知道从“较小”的newlib中还可以获得什么。我建议对这些定义的源代码进行grep，并在邮件列表中询问更多节省内存的方法。：-）这正是我在做Z.T.建议的事情时注意到的。我知道，针对大小优化的标志只会减少代码大小，而对于这个特定函数，它使用更少的堆栈这一事实只是一个令人高兴的巧合。但正如我在评论中所说的，我想知道这还能获得什么，并且想尝试一下。我想说的是，为了确保您知道库是如何构建的，您要么需要从库提供商那里获取信息（如果包含可能提供线索的构建脚本），要么根据自己的需求自行构建。