Vitaliy wrote:

> Vitaliy said:
>>> 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.
> 
> Gerhard said:
>> In the same condescending tone you're using sometimes I could respond
>> here that you probably just don't see how it could be done with
>> static memory, but I thought carefully about this and decided not to
>> say it.
> 
> Now, tell me that the sentence above does not imply that Gerhard
> knows how to replace DA with SA in every situation (which I don't,
> due to my inexperience).

I'd say you could replace it if you wanted to. But that's not really the
point. 

(But if you want to go there, your claim "is not a viable option" is
generic, implying that neither you nor I know how to make it a viable
option. I assume that when you're speaking for you, you know what you're
talking about, so I assume that you don't know how to make it a viable
option. But I think that I do know how to make it a viable option, and I
also think that I'm not alone with this. Which is the basis of the cited
phrase.)


>> Vitaliy, you never explained how you can make heap usage predictable.
>> Of course I don't mind if you disagree -- as I see it, this is your
>> problem not mine --, but thing is that as long as you just say
>> "believe me" without presenting any further explanation, I for one
>> won't believe you and take the lack of further explanation for an
>> absence of good arguments :)
> 
> Gerhard, who is really being condescending, you or me? I don't recall
> the last time I questioned your experience.

I didn't question your experience. But where you don't provide evidence
or even explanation, I take mine (where I have the evidence and the
explanation) any day.

> Have you read Terry's reply? I don't have much to add to it, except
> that if dynamic allocation was 1/10 as evil as you and Olin make it
> out to be your computer would not get past the booting phase, and
> your router would crash every five minutes.

My computer is a system that's not representative for all or most or
even many embedded systems. Most applications on my computer (including
the operating system itself) simply fail, more or less gracefully, when
they can't allocate from the heap. I wouldn't like my car's engine
control system work the way my computer works -- not even the way how my
router works. A typical desktop (and even server) system is not built
with predictability in mind, it's built with "add more RAM if you run
out of it" in mind.

Actually, both Windows (I know) and Linux (possibly, I seem to remember
it does) contain several parts where system-internal lists are not
dynamically allocated according to need but rather statically allocated
arrays (or something similar), with a fixed maximum number of elements.


> It all depends on the application.

Exactly my point. This is what I said, nothing more: there are some
applications where using the heap makes the whole thing more difficult
to predict, and therefore it makes it more difficult to guarantee
operation per spec -- if the spec contains operations that may not fail
within the constraints of the spec. 

> And I still stand by my assertion that there are situations where SMA
> is simply not practical, therefore in those cases discussing the evil
> attributes of DMA is pointless (it is the only option).

And I stay by my statement that there's always a way to implement a
given spec without using the heap, and where the constraints imposed by
the spec make the use of the heap the worse choice, I don't use it (and
advise against using it). What's your problem with this?

> [...] give me a list of these critical applications [...] where using
> the heap is "prohibiting".

For example, most applications where a failure to allocate memory
(malloc() returning NULL) is not an option fall into this category. If
you have to guarantee that this can't happen when the device is operated
within spec, you're in a different ball game than when you simply may
display to the user "not enough memory". 

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