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.

Of course that's not what I'm saying, it's what the strawman you created is 
saying. :)


> 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.

My point was that your question isn't  fair ("When will you stop beating 
your wife?"). How can you guarantee that your compiler doesn't have a bug 
that won't cause your program to fail? Can you guarantee that your 100k line 
program doesn't have a bug that will crash it in the worst possible 
situation?

Nothing is guaranteed. You and I try to use a disciplined approach to 
programming to try to minimize the chances of our code misbehaving. DMA is 
no different.


>> 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,

"Uncommon"? It's debatable. It certainly isn't at all unusual to see it done 
this way in desktop apps. You typically have to create an object before you 
can use it, even if it's a COM port component.


> B) you still have to design the memory usage if you want
> to guarantee that it fits,

Not sure what you mean. I guess I fail to see how (why) the design of memory 
usage would be an issue with DMA but not SMA.


> 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 hard for me to explain this in a short post, but there is a difference: 
in some cases creating variables dynamically is advantageous from a 
programming POV, even if you create them at the very beginning and don't 
ever destroy them.


>> 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.

I'm not sure why it's apparently so confusing, but I know I said we use 
*both* kinds. There are the "create once, destroy never" objects and there 
are objects that get created and destroyed numerous times throughout the 
life of the program.

Yes, it's more dangerous to do it this way, and there are times when it gets 
me in trouble, but with proper coding practices it's no worse than using 
pointers.

I want to reiterate the fact that in some situations using SMA is not a 
viable option, so in those situations talking about its merits is completely 
pointless.


> (That's where you probably added
> your own runtime support that shows you how much memory is occupied
> etc.)

Not *me* personally, but - yes.

Vitaliy 

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