>>Consider a laser printer, a nice dedicated system that does the same
>>thing all day long. Many printers allow one to add additional RAM.
>>At power up it determines the available RAM and allocates it
>>accordingly. Once allocated it might never be free()d. The code
>>will be more readable calling a routine called malloc() (or any other
>>name one would like). It could be done other ways, but the code
>>would be much less readable.
>>
>>Postscript does do dynamic allocation. A routine called malloc() may
>>or may not be a good way to do it in a Postscript (or compatible)
>>printer.
>>
>>For the most part, I agree with you, but I think there are some exceptions.
>
>
> Thanks; that makes good sense. Notice, though, that with the possibility
> of expansion memory, the resources are not known at coding time.
>
> Jerry
This also applies to the situation where I feel comfortable for using
malloc(): in library code where free() will never be called. I've even
implemented assign-only heaps to support this.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Reply by glen herrmannsfeldt●January 6, 20052005-01-06
Jerry Avins wrote:
(snip)
> There are some processors that are strictly Harvard, some with flat
> memory, and some with multiple banks each with its own bus where the
> banks are general purpose. The 6502 has a pin that asserts "instruction
> fetch" that can be used as a 17th address bit to overlay ROM and RAM.
> You use the processor you have, and in most cases, code for that one alone.
The 8086 had pins to decode the segment externally, you you could
have two extra address bits. Code segment, stack segment, data segment,
and extra segment could each have its own address space. Though
code in ROM everything else in RAM probably makes more sense.
I don't know if this is still there on later processors.
-- glen
Reply by Raymond Toy●January 6, 20052005-01-06
>>>>> "Jerry" == Jerry Avins <jya@ieee.org> writes:
Jerry> Stephen Maudsley wrote:
Jerry> ...
>> I was thinking about systems with several sources of differeent sized
>> tasks with different priorities, say a conferencing controller with
>> different protocols on incoming calls. Mallocing dynamic buffers by the
>> call handler might be the easiest way to contain all of the call
>> variable stuff in one module.
Jerry> Malloc isn't guaranteed to return a valid pointer; it can fail. To my
Jerry> simple mind, if there's enough memory so that malloc is sure to succeed,
Jerry> you don't need it.
To complicate things even further, even if there is enough memory
available, malloc can still fail because the malloc heap has become
fragmented and can't satisfy the request, because there's not block
large enough.
I bet the use of malloc in embedded systems is mostly a convenience.
Sometimes necessary, of course, when your embedded system is very
complex, like a cell phone with all kinds of apps. It would be hard
to allocate all the memory upfront and recycle manually.
Ray
Reply by Jerry Avins●January 6, 20052005-01-06
Randy Yates wrote:
> Jerry Avins <jya@ieee.org> writes:
>
>>[...]
>>I've written programs that PUSHed a whole bunch of constants, then
>>executed the stack. Some people have trouble believing it, but as
>>far as memory is concerned, there's no difference in structure
>>between code and text.
>
>
> (Did you mean "code and data"?)
I was trying for high contrast. I had in mind the guy with the new CS
Masters who asked me how hardware distinguishes between numbers and
ASCII and dismissed me as woefully ignorant when I told him that it doesn't.
> There is in some processors, Jerry - especially DSPs. Code space
> and data space are separate address spaces, in general. At least
> on the TI TMS32054x they are. (There are some exceptions, but
> let's not get hung up in the details.)
There are some processors that are strictly Harvard, some with flat
memory, and some with multiple banks each with its own bus where the
banks are general purpose. The 6502 has a pin that asserts "instruction
fetch" that can be used as a 17th address bit to overlay ROM and RAM.
You use the processor you have, and in most cases, code for that one alone.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by ●January 6, 20052005-01-06
Jerry Avins <jya@ieee.org> writes:
> [...]
> I've written programs that PUSHed a whole bunch of constants, then
> executed the stack. Some people have trouble believing it, but as
> far as memory is concerned, there's no difference in structure
> between code and text.
(Did you mean "code and data"?)
There is in some processors, Jerry - especially DSPs. Code space
and data space are separate address spaces, in general. At least
on the TI TMS32054x they are. (There are some exceptions, but
let's not get hung up in the details.)
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
randy.yates@sonyericsson.com, 919-472-1124
Reply by ●January 6, 20052005-01-06
On Thu, 06 Jan 2005 09:19:23 -0500, Jerry Avins <jya@ieee.org> wrote:
>> I was thinking about systems with several sources of differeent sized
>> tasks with different priorities, say a conferencing controller with
>> different protocols on incoming calls. Mallocing dynamic buffers by the
>> call handler might be the easiest way to contain all of the call
>> variable stuff in one module.
>
>Malloc isn't guaranteed to return a valid pointer; it can fail. To my
>simple mind, if there's enough memory so that malloc is sure to succeed,
>you don't need it.
;-) I can understand your way of thinking Jerry... at some point I've
seen some documents from TI about configuring DSP/BIOS for "static
systems" - there was also somethign about "dynamic systems" - I never
investigated the latter - however I do believe there are applications
that require use of malloc/free (sorry - for my mistakes before when I
wrote malloc/delete ;-))
Reply by Jerry Avins●January 6, 20052005-01-06
Shawn Steenhagen wrote:
...
> Jerry et al.
>
> In our typical DSP systems, we use what I call "psuedo dynamic" or
> "start-up" dynamic memory allocation in which the memory needed for various
> "objects" (LMS filters, IIR & FIR filters, etc) are allocated off a static
> heap at start up. Configuration information read from Flash can thereby be
> used to change the characteristics of the system without a re-compile (i.e.
> the same compile-time build of software can support different system
> attributes such as filter length, IIR filter order etc).
>
> For what its worth, we stay away from malloc( ) and use our own memory
> allocation functions that can allocate memory from a number of different
> static heaps as well as enforce address alignment for use with circular
> buffers. The start address and size of the heaps are automatically
> determined at the link process so that all possible memory within a device
> is available for use.
Thanks for that broader view. I always like expanding my horizons.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by ●January 6, 20052005-01-06
On Thu, 06 Jan 2005 09:11:22 -0500, Jerry Avins <jya@ieee.org> wrote:
>It was you, wasn't it, who brought up the case of insufficient memory
>for two different codecs that a base station had to deal with?
yes... that's right - it was me... but what I mean was insufficient
memory for "data" - meaning - applications use memory for storing data
and all that - for example - image processing algorithms (I know I'm
drifting away from cell-phone-world) - use big buffers for
manipulating images applying filters and all that... so - that's what
I meant by insufficient "resources"...
>That depends. I've written programs that PUSHed a whole bunch of
>constants, then executed the stack. Some people have trouble believing
>it, but as far as memory is concerned, there's no difference in
>structure between code and text.
;-) well - I do believe you - it is possible to push data to stack and
execute it ;-) wait - isn't it called "dynamic programming"? where
code is changed dynamically? the code being executed is changing
itself dynamically... but I get the impression that we drifted far too
far from the original subject ;-)
sadly nobody answered my doubts about how the cell-phone system works
with all the codecs ;-) did you move forward about mallocs Jerry? ;-)
Reply by Jerry Avins●January 6, 20052005-01-06
Stephen Maudsley wrote:
...
> I was thinking about systems with several sources of differeent sized
> tasks with different priorities, say a conferencing controller with
> different protocols on incoming calls. Mallocing dynamic buffers by the
> call handler might be the easiest way to contain all of the call
> variable stuff in one module.
Malloc isn't guaranteed to return a valid pointer; it can fail. To my
simple mind, if there's enough memory so that malloc is sure to succeed,
you don't need it.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by Jerry Avins●January 6, 20052005-01-06
glen herrmannsfeldt wrote:
>
>
> Jerry Avins wrote:
>
>> glen herrmannsfeldt wrote:
>
>
> (snip)
>
>> I know how to use malloc(). I'm one of those uptight programmers who
>> even checks to be sure it succeeds instead of simply assuming it. I have
>> made liberal use of EQUIVALENCE statements not only to conserve storage,
>> but to do sneaky type conversion. In C, I use UNIONs the same way.
>
>
>> My question was about using malloc() in code for embedded systems with
>> no off-line storage and all other resources known at coding time. The
>> only reasons I can think of are not complementary. If there are good
>> reasons, I'd like to know them.
>
>
> I tried not to disagree too much. I think there are uses, but
> the reasons are weak. One doesn't require virtual memory,
> and conserving memory is probably more important for real memory.
>
> Consider a laser printer, a nice dedicated system that does the same
> thing all day long. Many printers allow one to add additional RAM.
> At power up it determines the available RAM and allocates it
> accordingly. Once allocated it might never be free()d. The code
> will be more readable calling a routine called malloc() (or any other
> name one would like). It could be done other ways, but the code
> would be much less readable.
>
> Postscript does do dynamic allocation. A routine called malloc() may
> or may not be a good way to do it in a Postscript (or compatible)
> printer.
>
> For the most part, I agree with you, but I think there are some exceptions.
Thanks; that makes good sense. Notice, though, that with the possibility
of expansion memory, the resources are not known at coding time.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������