Vitaliy wrote:

> Gerhard Fiedler wrote:
>> All agreed, but this is probably a device that may fail if the memory
>> it needs isn't available -- typically because it has a user
>> interface and user configuration possibilities, and when it fails
>> it's because the user added too much functionality for the available
>> memory. Your typical small-micro embedded device may not fail within
>> specified operation constraints, and memory must be guaranteed to be
>> available. Which requires the memory design I was talking about. 
>> 
>> These are two quite different scenarios, and probably should be
>> discussed separately. 
>> 
>> Or -- if I'm mistaken --, how do you guarantee that a program that
>> uses heap allocation doesn't fail (due to lack of memory) when
>> operated within specs?
> 
> First of all, how do you guarantee that _any_ program does not fail?
> AFAIK it is a programming axiom that you cannot prove that a program
> of any reasonable complexity is correct. 

Now, come on... this is really a different thing. By the same token
someone could say that since it is not possible to guarantee that a
program is correct, we should do away with all design and quality
control. I know that this is not what you do, and so it can't be what
you meant.

Just because I can't prove that my program is correct doesn't mean I
shouldn't make sure that what I can know about it fits the specs.


> If you were to simply replace static memory allocation (SMA) with
> dynamic memory allocation (DMA) by allocating memory only on startup
> and not freeing it, then there is no downside to using DMA from a
> "safety" POV. You just make sure that every call to malloc() has an
> error handler that prints a message if the device is out of memory.
> You will get an error when you first run the program, as opposed to
> at compile time. 

Of course. But A) this is a very special and uncommon form of using
dynamic memory, B) you still have to design the memory usage if you want
to guarantee that it fits, and C) there is probably little difference in
such a scenario between static and dynamic memory usage -- simply
because the memory usage is hardcoded into the program and predictable.

It's this "predictable" aspect that for /normal/ usage of dynamic memory
is the problem with embedded systems that are expected to work according
to spec. This is what I was talking about: normal usage of dynamic
memory via malloc/free during the normal operation of the program, for
example to allocate additional space for buffers in times when longer
buffers are needed (and free it afterwards). 


> If you must use DMA in your program to get its benefits, then it's
> pointless to argue whether it's inferior to the SMA or not. You just
> need a bit more discipline, think about the worst case situations,
> and write a test suite that simulates them. 

You talk about a very specifically limited usage of dynamic memory: only
on startup, never freed and hardcoded into the device. These
restrictions are not commonly in mind when talking about using dynamic
memory in general; in fact, typically dynamic memory is used when these
restrictions are not given (allocation during the operational phase,
allocation of memory for data structures that are not known beforehand,
in type or number). So IMO you should always be quite clear that you're
talking about using dynamic memory with these specific restrictions, or
else people won't really understand what you're talking about. I, for
one, was not talking about this form, and for the more general form, I
think my statements still stand.

So yes, talking about your specific form of using dynamic memory, it's
quite similar to using static memory -- with the exception of lacking
compiler support for memory layout. (That's where you probably added
your own runtime support that shows you how much memory is occupied
etc.) 

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist