Re: Memory management strategy
- From: Keith Thompson <kst-u@xxxxxxx>
- Date: Mon, 30 May 2005 20:37:26 GMT
Paul Mesken <usurper@xxxxxxxxxx> writes:
> On 30 May 2005 16:25:43 GMT, roberson@xxxxxxxxxxxxxxxxxx (Walter
> Roberson) wrote:
[...]
>>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.
>
> The use of registers instead of the stack doesn't need inlining. There
> are often calling conventions that can control this behaviour (of
> course, such things are depending on the capabilities of the compiler
> and linker).
A function call, depending on the calling conventions, might require
the use of some registers; inlining the call might make those
registers available for other purposes (like caching local variables).
This is, of course, extremely system-specific.
> "Inline functions" are more liable to use more memory since the whole
> function is put in place of the code that calls such a function. If
> some inline function is called at 20 different places in the program
> then the code of that function is placed 20 times in the code. If the
> function is big then this might give a quite substantial code size
> penalty. The fact that the function takes a little bit less code
> because it doesn't need to do stack manipulations (or less stack
> manipulations) doesn't amount to a lot when the code of that function
> is copied 20 times in the program.
On the other hand, inlining a function can provide more opportunities
for optimization. For example:
void foo(int x)
{
if (x < 0) {
/* some stuff */
}
else if (x == 0) {
/* some other stuff */
}
else {
/* yet other stuff */
}
}
If a call to foo() is inlined in a context where the compiler knows
that x is positive, the "some stuff" and "some other stuff", along
with the tests, can be eliminated. Add to that the savings from
eliminating the entry and exit code, and you just might get less code
with 20 inlined copies than with 20 calls to a single function. Or
you might not.
[...]
> Yes, it's only sensible to use packed values when the extra amount of
> code necessary to manipulate such values is less than the amount of
> memory that was saved by having such packed values.
For single variables, it rarely makes sense to use a smaller type.
For arrays, you can often save space by using an array of char or
short rather than int or long, or an array of float rather than double
-- but of course you need to make sure that the values will actually
fit in the smaller type.
One more possible tip: In embedded systems, my understanding is that
code and constant data are typically in ROM, while variable data is
typically in RAM, and that ROM is often much more plentiful than RAM.
It might make sense to write a large amount of code, or declare a
large constant array, to save a little bit of run-time data.
And of course *all* this stuff is extremely system-specific. None of
this advice should be followed blindly. Understand the system you're
using, and *measure*.
I'm sure the folks in comp.arch.embedded know more about this stuff
than I do.
--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.
- Follow-Ups:
- Re: Memory management strategy
- From: Paul Mesken
- Re: Memory management strategy
- References:
- Memory management strategy
- From: ira2402
- Re: Memory management strategy
- From: Paul Mesken
- Re: Memory management strategy
- From: Walter Roberson
- Re: Memory management strategy
- From: Paul Mesken
- Memory management strategy
- Prev by Date: Re: WAV file question
- Next by Date: Re: Is there a way to write append rewrite a XML Multilingual file
- Previous by thread: Re: Memory management strategy
- Next by thread: Re: Memory management strategy
- Index(es):
Relevant Pages
|
