| Author |
Message |
karol kluska
Guest
|
 Posted:
Thu Jan 06, 2005 2:23 am Post subject:
Re: malloc |
|
|
On Wed, 05 Jan 2005 13:03:09 -0500, Jerry Avins <jya@ieee.org> wrote:
| Quote: | How would you use it? Presumably, when you release memory holding the
code for one codec, you have to bring in the software for the other.
Where might that come from? Let's assume that we transfer it from slow
ROM to fast RAM. Why is allocate/deallocate needed? Why not just
overwrite the old codec code?
|
? hm... you lost me here... I thought malloc/delete is used for
allocating memory for _data_ and not _code_... or did I miss
something?
| Quote: | Anyway, in a base station, wouldn't it make sense to just provide enough
memory for the whole job? The change-over time from codec to codec
probably wouldn't be acceptable.
|
well - to be hones - as I said before - I know very little about
cell-phone systems - I was more hopeing to hear from somebody who
"just knows" the answer... I just wanted to learn something...
but again - I think you're confusing data space with code space... you
(well - maybe not you personally) use malloc to allocate space for
dynamic data structures (lists, queues etc) - but also for buffers and
stuff... but then - again - what do I know? it's all theory - I don't
have years of professional experience to back it up... |
|
| Back to top |
|
 |
Shawn Steenhagen
Guest
|
| Posted:
Thu Jan 06, 2005 2:46 am Post subject:
Re: malloc |
|
|
"Jerry Avins" <jya@ieee.org> wrote in message
news:342jmfF40o4dnU1@individual.net...
| Quote: | Simone Winkler wrote:
Hello,
[SNIP]
Maybe you can help me to understand how malloc() might be used in an
embedded system.
[SNIP]
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
|
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.
-Shawn |
|
| Back to top |
|
|
Stephen Maudsley
Guest
|
| Posted:
Thu Jan 06, 2005 3:01 am Post subject:
Re: malloc |
|
|
Jerry Avins wrote:
| Quote: | glen herrmannsfeldt wrote:
Jerry Avins wrote:
(snip regarding malloc() and DSP programming)
Maybe you can help me to understand how malloc() might be used in an
embedded system. I assume that there is no virtual memory (swapping to
disk) available,
Well, dynamic storage allocation was in use on machines without
virtual memory for many years. OS/360 for one example.
and that the routines to be run use fixed-size arrays and buffers.
Now, this is the question. If they are fixed size static allocation
is likely best. (Some non-DSP systems have problems doing large static
allocation, but that is a different question.)
It is never necessary to allocate memory unless it will
also be de-allocated later.
It is also nice when you don't know the size initially, and
also don't know the available memory on the machine it will
run on. In that case, it may only be deallocated when the
program is done.
For the DSP case using a C #define so that it can
be recompiled with a machine specific size may also work.
Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the space
I needed at compile time. What would you use malloc() for?
In the old Fortran days EQUIVALENCE was used to give more than one
name to the same (statically allocate) storage. That allowed one
to conserve memory without making it too ugly. As many Fortran
systems only did static allocation, one would declare arrays large
enough for the largest case.
If the target is a dedicated device with a known amount of storage,
and always performing the same function I have to agree that static
allocation should be fine. To use memory sequentially for different
routines when the size for each is not known at compile time
it can still be useful to have malloc().
The original K&R C book (and maybe the second edition) have as an
example a malloc() that uses a static array to allocate from.
Glen,
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 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. |
|
| Back to top |
|
|
Ian
Guest
|
| Posted:
Thu Jan 06, 2005 5:06 pm Post subject:
Re: malloc |
|
|
When writing the modulators for a variety of Inmarsat services I had
exactly this problem. The modulation scheme, data rates and data
framing vary wildly according to the service type being provided
(symbol rates of 4 to 21k symbols per second, FSK, BPSK, QPSK...). The
code was implemented as a set of overlays that were loaded out of ROM
into the DSP fast program RAM. Each overlay had its own static memory
allocation. This worked as the operating modes were mutually exclusive
with just a small area if static common memory for the mode (overlay)
management code to use. Once the scheme had been set out it worked
well because it was simple.
Ian |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Thu Jan 06, 2005 7:11 pm Post subject:
Re: malloc |
|
|
karol kluska wrote:
| Quote: | On Wed, 05 Jan 2005 13:03:09 -0500, Jerry Avins <jya@ieee.org> wrote:
How would you use it? Presumably, when you release memory holding the
code for one codec, you have to bring in the software for the other.
Where might that come from? Let's assume that we transfer it from slow
ROM to fast RAM. Why is allocate/deallocate needed? Why not just
overwrite the old codec code?
? hm... you lost me here... I thought malloc/delete is used for
allocating memory for _data_ and not _code_... or did I miss
something?
|
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? Malloc
allocates memory. If one is not constrained by rigid typing (the way men
and women are segregated in some houses of worship), it can be used to
manage overlays of relocatable code. If not that, what did you have in mind?
| Quote: | Anyway, in a base station, wouldn't it make sense to just provide enough
memory for the whole job? The change-over time from codec to codec
probably wouldn't be acceptable.
well - to be honest - as I said before - I know very little about
cell-phone systems - I was more hopeing to hear from somebody who
"just knows" the answer... I just wanted to learn something...
but again - I think you're confusing data space with code space... you
(well - maybe not you personally) use malloc to allocate space for
dynamic data structures (lists, queues etc) - but also for buffers and
stuff... but then - again - what do I know? it's all theory - I don't
have years of professional experience to back it up...
|
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.
Jerry
--
Engineering is the art of making what you want from things you can get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Thu Jan 06, 2005 7:16 pm Post subject:
Re: malloc |
|
|
glen herrmannsfeldt wrote:
| Quote: |
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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Thu Jan 06, 2005 7:19 pm Post subject:
Re: malloc |
|
|
Stephen Maudsley wrote:
...
| Quote: | 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
karol kluska
Guest
|
| Posted:
Thu Jan 06, 2005 7:21 pm Post subject:
Re: malloc |
|
|
On Thu, 06 Jan 2005 09:11:22 -0500, Jerry Avins <jya@ieee.org> wrote:
| Quote: | 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"...
| Quote: | 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? ;-) |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Thu Jan 06, 2005 7:23 pm Post subject:
Re: malloc |
|
|
Shawn Steenhagen wrote:
...
| Quote: | 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
karol kluska
Guest
|
| Posted:
Thu Jan 06, 2005 7:24 pm Post subject:
Re: malloc |
|
|
On Thu, 06 Jan 2005 09:19:23 -0500, Jerry Avins <jya@ieee.org> wrote:
| Quote: | 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 ;-)) |
|
| Back to top |
|
|
Randy Yates
Guest
|
| Posted:
Thu Jan 06, 2005 9:01 pm Post subject:
Re: malloc |
|
|
Jerry Avins <jya@ieee.org> writes:
| Quote: | [...]
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 |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Thu Jan 06, 2005 10:22 pm Post subject:
Re: malloc |
|
|
Randy Yates wrote:
| Quote: | 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.
| Quote: | 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
Raymond Toy
Guest
|
| Posted:
Thu Jan 06, 2005 10:54 pm Post subject:
Re: malloc |
|
|
| Quote: | "Jerry" == Jerry Avins <jya@ieee.org> writes:
|
Jerry> Stephen Maudsley wrote:
Jerry> ...
| Quote: | 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 |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Thu Jan 06, 2005 11:04 pm Post subject:
Re: malloc |
|
|
Jerry Avins wrote:
(snip)
| Quote: | 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 |
|
| Back to top |
|
|
john
Guest
|
| Posted:
Fri Jan 07, 2005 6:52 am Post subject:
Re: malloc |
|
|
Jerry Avins wrote:
| Quote: | glen herrmannsfeldt wrote:
Jerry Avins wrote:
(snip regarding malloc() and DSP programming)
Maybe you can help me to understand how malloc() might be used in
an
embedded system. I assume that there is no virtual memory
(swapping to
disk) available,
Well, dynamic storage allocation was in use on machines without
virtual memory for many years. OS/360 for one example.
and that the routines to be run use fixed-size arrays and buffers.
Now, this is the question. If they are fixed size static
allocation
is likely best. (Some non-DSP systems have problems doing large
static
allocation, but that is a different question.)
It is never necessary to allocate memory unless it will
also be de-allocated later.
It is also nice when you don't know the size initially, and
also don't know the available memory on the machine it will
run on. In that case, it may only be deallocated when the
program is done.
For the DSP case using a C #define so that it can
be recompiled with a machine specific size may also work.
Although I have sometimes needed to use the
same memory space sequentially for different routines, I've never
encountered a situation that prevented me from allocating all the
space
I needed at compile time. What would you use malloc() for?
In the old Fortran days EQUIVALENCE was used to give more than one
name to the same (statically allocate) storage. That allowed one
to conserve memory without making it too ugly. As many Fortran
systems only did static allocation, one would declare arrays large
enough for the largest case.
If the target is a dedicated device with a known amount of storage,
and always performing the same function I have to agree that static
allocation should be fine. To use memory sequentially for
different
routines when the size for each is not known at compile time
it can still be useful to have malloc().
The original K&R C book (and maybe the second edition) have as an
example a malloc() that uses a static array to allocate from.
Glen,
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.
Jerry
--
Engineering is the art of making what you want from things you can
get.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
Uptight? That's just good practice. I had a set-top digital cable box
that crashed frequently, and not checking return codes could be one of
the reasons. Another common problem in C++ systems is invoking a member
function after freeing the object. The call will succeed until the
object's memory has not been reused, but after than watch out, you
could execute the wrong code!
John |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in