karol kluska wrote: ...> imagine a cell phone... there is a DSP chip in it that performs voice > encoding/decoding - lets say the phone is using codec A... > > there is another cell phone with another DSP chip in it... that one is > using codec B (A and B are different coding methods = different > codecs) > > now - imagine a "base station" that the above cell phones are talking > to - that base station has to be able to understand both (or n in > general) coding techniques - it's done by running different software > on the same DSP chip - everything happens "on the fly" - the DSP chip > in the base station is dynamicaly choosing which coding technique to > use - without reseting the chip of course... oh... and let's say there > are only resources to run 1 codec at a time... is there a need for > malloc/delete?... 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? 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. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
malloc
Started by ●January 2, 2005
Reply by ●January 5, 20052005-01-05
Reply by ●January 5, 20052005-01-05
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. �����������������������������������������������������������������������
Reply by ●January 5, 20052005-01-05
Jerry Avins wrote:> Simone Winkler wrote: > > >>Hello, >> >>I'm developping code for a C6713 DSP (actually it's the D.SignT-module with >>the C6713 on it). >>I'm trying to use malloc() but it doesn't seem to work. In the beginning I >>always received a null pointer. After a long while of searching my mistake I >>detected the section in the DSP/BIOS configuration for malloc(). I pointed >>it to SBSRAM and to SDRAM but both solutions didnt work - in the end I got >>an error that told me that I tried to read data from memory location ... in >>L2. The command I use simply says "malloc(1)" - just to try... >>At the moment I'm using the emulator because I can't run the board at home, >>but I think this cannot be the problem. >> >>Can you help me? >> >>Thank you, >>Simone > > > 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, and that the routines to be run use fixed-size arrays > and buffers. It is never necessary to allocate memory unless it will > also be de-allocated later. 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? > > JerryI have written library code for embedded systems that use malloc(). The ground rules we operated under was that you could use malloc() at startup to get necessary memory, but that you _never_ used free(). The rational for using malloc() was because insisting on knowing array sizes and whatnot would make the code significantly less reusable, with a correlary that it would have been significantly harder to use one piece of code to control two or more identical things (some of my motor controller code happily controls three motors of two dissimilar types out of the same set of C++ code, with user-added wrappers). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●January 5, 20052005-01-05
karol kluska wrote:>>Did I seem to imply that malloc() shouldn't be used? If so, I wasn't >>clear. I asked how it might be used, i.e., what makes it useful. > >-- snip --> > and please excuse me my language problems...Sorry, you cannot be excused where you have not sinned. Were I able to speak your native language better than you speak English, _then_ I could get on your case.> > have a nice day everybody...Allocating memory in a deeply embedded system carries the danger that you may run out of memory. This is a very manageable problem, so allocating memory doesn't cause that much pain. Deallocating memory out of a heap, however, leaves you with a fragmented heap. It is painfully common in systems without garbage collection to have heaps fragment and the system fail. There are a number of more or less valid methods for dealing with this. You can not do it at all, forcing yourself into only using fixed-size buffers and possibly circular buffers, but this may not work. The safest way to actually use some form of dynamic allocation is to use a pool of fixed-size buffers and allocate out of that. When you do this your pool can be as fragmented as can be, but if there's a free buffer you'll be able to get it. The down side is that you have to write your code to cope with the buffer size, so data that comes in unpredictable lengths will either consume unnecessary buffer space or will have to be daisy-chained together (and the chains deallocated gracefully). The next safest way that I know of is to use multiple heaps, separated by priority or by the sizes of the chunks. I view this method with deep suspicion, and have not used it. The last method, that I _have_ used with success, is to only use a heap in a context where there will be somebody standing by to cycle power. In this case I've used it for a service interface to handle sending multiple streams to one terminal. The heap is used, and can fragment, but if it does the worst that will happen is that a service guy or an engineer will utter a mild oath before hitting reset. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●January 5, 20052005-01-05
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. -- glen
Reply by ●January 5, 20052005-01-05
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?>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...
Reply by ●January 5, 20052005-01-05
"Jerry Avins" <jya@ieee.org> wrote in message news:342jmfF40o4dnU1@individual.net...> 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
Reply by ●January 5, 20052005-01-05
Jerry Avins wrote:> 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.
Reply by ●January 6, 20052005-01-06
karol kluska wrote:> 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?>>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. �����������������������������������������������������������������������
Reply by ●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. �����������������������������������������������������������������������
