问题描述
大家好，
我们正在为小型嵌入式操作系统开发sw，我们的内存有限。
我们正在寻找算法关于此的链接和文章。
目标是有效利用少量内存 - 意味着 -
分配固定长度块/可变长度块。
谢谢。
你可以为嵌入式系统尝试comp.programming的数据结构和算法，以及
comp.arch.embedded。 comp.lang.c用于讨论
标准C编程语言，这不是你的问题。
大约。
劳伦斯
好吧，就C而言，我可以想到几个提示：
- 不是为每个小对象分配内存，而是分配一块大的内存并自行管理。每个单独的分配
带来一些开销和函数，如malloc和calloc可能
有他们分配的最小大小（例如，如果你分配内存
表示2个字节，可能会发现分配了16个字节，因为
分配的工作方式非常精细）。另外，分配一个大的
块也可以减少内存泄漏的危险。
- 不要使用编译器的速度优化。这些可能涉及
交易内存以获得速度（例如，循环展开）。
- 使用您需要的最小大小的数据类型。通常情况下，程序员会自动使用int''s $
，其中短''和char'可以使用
。您甚至可以使用
位域打包一些值。就结构而言：请注意，由于填充，你可能会丢失一些额外的
内存。
- 如果可以的话，避免使用递归函数。虽然递归函数
经常会减少代码大小，但它们可能会变得非常耗费内存。
- 不要传递大对象（比如struct'的价值，但参考，如果
你可以。
- 使用全局变量可能会减少内存使用量（通过更少
参数）在某些情况下，但这被认为有点难看，并且是一个微优化的
位:-)
- 使用const where适当的（特别是对于数组）。
此外：您可以考虑压缩数据并将数据写入某些大容量存储设备（如果您的嵌入式系统有一）如果
数据长时间没用。
现在（我不能帮助自己;-)如果全部否则那么你可能会想要求助于装配，这通常会允许各种各样的
欺骗，甚至可以进一步减少代码大小（其中一个最大的
臭名昭着的方法是自修改代码，但你的系统必须是
能够允许这样的事情。）
好吧，就C而言，我可以想到几个提示：
通常很好的建议，但其中一些并不总是有效。
- 不要使用编译器的速度优化。这些可能涉及交换内存以获得速度（例如，循环展开）。
内联短程序可以 - 有时 - 占用的内存少于调用例程的
，因为寄存器有时可以直接使用
" as-is"，无需保存重要值并生成
调用并拥有返回堆栈。
某些编译器允许控制当展开完成时 - 例如，
可能允许您对代码的复杂性设置上限
要展开。
因此我不会说不要使用优化：我会说
调查可用的选项及其效果 - 并且
为下一个编译器更新
道路的可能性做好了准备，权衡可能会改变。
- 使用您需要的最小大小的数据类型。通常情况下，程序员会自动使用int''，其中可以使用short'和char'。您甚至可以使用
位域打包一些值。
这可能取决于数据的使用频率和一种类型的多少b $ b，以及架构。有些系统需要
更长的指令来访问比它们优化的更小的数据。
特定用于位域。
- 避免递归功能，如果可以的话。虽然递归函数通常会减少代码大小，但它们可能会变得非常耗费内存。
将递归函数重写为迭代形式（总是
）可能需要更多的内存和更低的效率而不是留下
它是递归的 - 在迭代形式中，你必须做动态内存管理，链接列表或增长数组，所有代码
和代表的内存开销。
- 在某些情况下使用全局变量可能会减少内存使用量（通过较少的
参数），但这被认为有点难看，而且是一点点一个微优化： - ）
使用全局变量也可以增加代码大小，具体取决于
架构。有时会有更短的指示将
引用到对象near附近。基址寄存器（例如，在16位偏移内）
而全局可能需要完整地址。在另一方面，一些架构有简短的指示，用于在低内存中引用
对象。 （例如，第一个64 Kb），并且在那些架构上，可以位于该低内存内的全局内容。 block可能有最小的指令
。你真的需要知道你的建筑
才能做到这一点。
-
哦，要成为Blobel！
Hi All,
We are developing sw for a small embedded OS and we have limited
memory.
We are looking for algorithms, links, and articles about this.
The goal is efficient utilization of small amount of memory - means -
allocation for fixed length blocks / variable length blocks.
Thanks.
You could try comp.programming for datastructures and algorithms and
comp.arch.embedded for embedded systems. comp.lang.c is for discussing the
standard C programming language which is not really what your question is
about.
Lawrence
Well, as far as C goes, I could think of a couple of tips :
- Instead of allocating memory for each small object, allocate a big
piece of memory and manage it yourself. Each individual allocation
comes with some overhead and functions like malloc and calloc might
have a minimum size they allocate (for example, if you allocate memory
for 2 bytes, it might turn out that 16 bytes were allocated because
allocation works with such a granularity). Also, allocating one big
block also reduces the ever present danger of memory leaks.
- Don''t use speed optimizations of your compiler. These might involve
trading memory for speed (loop unrolling, for example).
- Use the minimum sized datatype you need. All too often, int''s are
used automatically by the programmer where short''s and char''s could
have been used. You might even be able to pack some values with
bitfields. As far as struct''s go : note that you might lose some extra
memory due to padding.
- Avoid recursive functions, if you can. Although recursive functions
often reduce code size, they might turn out to be very memory hungry.
- Don''t pass big objects (like struct''s) by value but by reference, if
you can.
- Using global variables might reduce memory usage (in passing less
parameters) in some cases but this is considered a bit ugly and is a
bit of a micro optimization :-)
- Use const where appropriate (especially for arrays).
Furthermore : you could think of compression of data and writing data
to some mass storage device (if your embedded system has one) if the
data isn''t used for a long time.
Now (I just can''t help myself ;-) if all else fails then you might
want to resort to Assembly which often allows for all kinds of
trickery that can even further reduce code size (one of the most
notorious methods was self modifying code, but your system must be
able to allow such a thing).
Well, as far as C goes, I could think of a couple of tips :
Generally good recommendations, but a few of them do not always work.
- Don''t use speed optimizations of your compiler. These might involve
trading memory for speed (loop unrolling, for example).
Inlining of short routines can -sometimes- take less memory than
calling the routine, as the registers can sometimes be used directly
"as-is", without having to save important values and generate the
call and have the return stack.
Some compilers allow control over when unrolling is done -- e.g.,
may allow you to place an upper limit on the complexity of the code
to be unrolled.
Thus I would not say "don''t use" the optimizations: I would say
"investigate the available options and their effects" -- and be
prepared for the possibility that the next compiler update down the
road, the tradeoffs might change.
- Use the minimum sized datatype you need. All too often, int''s are
used automatically by the programmer where short''s and char''s could
have been used. You might even be able to pack some values with
bitfields.
That can depend upon how often the data is used and how much
of one type there is, and upon the architecture. Some systems need
longer instructions to access smaller data than they were optimized for.
Particularily for bitfields.
- Avoid recursive functions, if you can. Although recursive functions
often reduce code size, they might turn out to be very memory hungry.
Rewriting a recursive function into its iterative form (which always
possible) can require more memory and lower efficiency than leaving
it recursive -- in the iterative form, you have to do dynamic memory
management, linked lists or growing arrays in place, with all the code
and memory overhead that represents.
- Using global variables might reduce memory usage (in passing less
parameters) in some cases but this is considered a bit ugly and is a
bit of a micro optimization :-)
Using global variables can also increase code size, depending on the
architecture. Sometimes there are shorter instructions for referring
to objects "near" a base register (e.g., within 16 bits offset)
whereas a full address may be required for a global. On the other
hand, some architectures have short instructions for referring to
objects in "low memory" (e.g., first 64 Kb), and on those architectures
a global that can be located within that "low memory" block might have
the smallest instruction. You really need to know your architecture
to get this kind of thing right.
--
Oh, to be a Blobel!
这篇关于内存管理策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！