Hi
I'm using DSP/BIOS 5 in a C++ project for the C6748. If I wish to dynamically allocate memory at run time should I use MEM_alloc/MEM_free, ie, the DSP/BIOS library functions, or simply use C++ builtin new and delete operators and assume that the compiler will sort it out? Does the compiler automatically map new and delete C++ calls to MEM_alloc and MEM_free? If not are there any arguments for using one approach over the other, eg, does one approach give more control and/or better/more predictable heap management?
I am a bit wary about the likelihood and/or consequences of heap fragmentation. When using delete or MEM_free is the freed space available immediately? For example, if I request a 1 MB block of memory and, for arguments sake, am returned a pointer to the base of the heap. If I then free this memory and then immediately request another 1 MB block of memory then (assuming that I can guarantee no other tasks have made any other memory requests in the meantime) can I be guaranteed that I would always get back a pointer to the same block of memory or might I get a pointer, say, 1 MB into the heap? In other words if this process were to repeat over and over could I ever run out of memory? Clearly in an ideal world where, by design, the lifecycle of each memory allocation request never overlaps those of other memory allocation requests I would always be given back the same block of memory from the start of the heap and memory fragmentation and the possibility of running out of memory should never occur!
Many thanks in advance
Tim
Tim JamesI'm using DSP/BIOS 5 in a C++ project for the C6748. If I wish to dynamically allocate memory at run time should I use MEM_alloc/MEM_free, ie, the DSP/BIOS library functions, or simply use C++ builtin new and delete operators and assume that the compiler will sort it out? Does the compiler automatically map new and delete C++ calls to MEM_alloc and MEM_free? If not are there any arguments for using one approach over the other, eg, does one approach give more control and/or better/more predictable heap management?
I would recomend MEM_alloc/MEM_free, but according to this page you can use new/delete as well:
http://processors.wiki.ti.com/index.php/Overview_of_C%2B%2B_Support_in_TI_Compilers#BIOS_and_C.2B.2B
The use of malloc for pure C is different:
http://processors.wiki.ti.com/index.php/DSP_BIOS_FAQ#Q:_Can_runtime_support_.28RTS.29_functions_be_called_when_using_DSP.2FBIOS.3F
Please alse see page 279 of document:
http://www-s.ti.com/sc/techlit/spru403
Tim JamesI am a bit wary about the likelihood and/or consequences of heap fragmentation. When using delete or MEM_free is the freed space available immediately? For example, if I request a 1 MB block of memory and, for arguments sake, am returned a pointer to the base of the heap. If I then free this memory and then immediately request another 1 MB block of memory then (assuming that I can guarantee no other tasks have made any other memory requests in the meantime) can I be guaranteed that I would always get back a pointer to the same block of memory or might I get a pointer, say, 1 MB into the heap? In other words if this process were to repeat over and over could I ever run out of memory? Clearly in an ideal world where, by design, the lifecycle of each memory allocation request never overlaps those of other memory allocation requests I would always be given back the same block of memory from the start of the heap and memory fragmentation and the possibility of running out of memory should never occur!
As long as the segment is free you should get the pointer to the same part of the memory. But please remember that if you are calling MEM_alloc/free from multiple task you might be trying to allocate in a task while the other one did not free the memory yet.
For memory management, please see chapter 5 of:
http://www-s.ti.com/sc/techlit/spru303
- Mariana
---------------------------------------------------------------------------------------------------------Please click the Verify Answer button on this post if it answers your question.---------------------------------------------------------------------------------------------------------