[C6416] allocation

What function are you calling to allocate the memory dynamically?

If you are not using DSP/BIOS, you should be using malloc. Please see page 152 of:

http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru187o

If you are using DSP/BIOS, you can use MEM_alloc. Please see page 282 of:

http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru403o

Both functions use a dedicated limited memory space to allocate memory, so there should not be overlapping. If there is not space left in the heap, the function will return a null pointer for malloc or MEM_ILLEGAL for MEM_alloc.

Mariana-

This answer repeats sections from two different documents that contain conflicting information, and does not address what happens when malloc() is used in a DSP/BIOS application.  As far as I can tell, there is no way to create a non-zero .sysmem section in a DSP/BIOS project -- for example, even entering a -heap option in the Build Options | Linker dialog is "overruled" by DSP/BIOS configured project.

Questions:

1) In DSP/BIOS configured applications, should code always use MEM_alloc()?  If using malloc() is also possible, then how to force .sysmem to be defined with non-zero length?

2) Is it possible to write code that deals with both situations?  For example the code looks for a pre-define macro (compile-time) or suitable symbol (link-time, checks the value at run-time) and makes an intelligent decision?

Thanks.

-Jeff  

Mariana said:

What function are you calling to allocate the memory dynamically?

 

If you are not using DSP/BIOS, you should be using malloc. Please see page 152 of:

 

http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru187o

 

If you are using DSP/BIOS, you can use MEM_alloc. Please see page 282 of:

 

http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=spru403o

 

Both functions use a dedicated limited memory space to allocate memory, so there should not be overlapping. If there is not space left in the heap, the function will return a null pointer for malloc or MEM_ILLEGAL for MEM_alloc.

Calling a malloc in BIOS will end up being the same as a call to MEM_alloc, BIOS overrides the default RTS malloc function. You can define what memory section that malloc goes to in the BIOS configuration utility, in the MEM section manager properties.

Jeff Brower said:

1) In DSP/BIOS configured applications, should code always use MEM_alloc()?  If using malloc() is also possible, then how to force .sysmem to be defined with non-zero length?

You can use either malloc or MEM_alloc, MEM_alloc has the advantage of allowing you to define what memory segment you allocate from in the call. You define the size of the heap (.sysmem equivalent) within the MEM section manager properties of the BIOS configuration utility.

Jeff Brower said:

2) Is it possible to write code that deals with both situations?  For example the code looks for a pre-define macro (compile-time) or suitable symbol (link-time, checks the value at run-time) and makes an intelligent decision?

You certainly could, using a preprocessor #ifdef #else setup would allow you to make code that functions both in BIOS with the MEM_alloc capability of defining the segment to use and with a normal malloc if you intend to build without BIOS, however you could also just use a malloc that will work in both assuming your BIOS configuration has a properly sized heap given to calls to malloc.

Bernie-

Bernie Thompson said:

Calling a malloc in BIOS will end up being the same as a call to MEM_alloc, BIOS overrides the default RTS malloc function. You can define what memory section that malloc goes to in the BIOS configuration utility, in the MEM section manager properties.

That does not match Mariana's info above, which indicates that malloc() and MEM_alloc() co-exist and do not use overlapping areas.

Bernie Thompson said:

You can use either malloc or MEM_alloc, MEM_alloc has the advantage of allowing you to define what memory segment you allocate from in the call. You define the size of the heap (.sysmem equivalent) within the MEM section manager properties of the BIOS configuration utility.

MEM_alloc has disadvantages also, such as not being callable from an SWI_posted code.  Is there some way to avoid the override and access the standard C lib malloc?   I wonder if we could pull it out of the library .src code and use as needed.   It would be advantageous to be able to create and control a heap section and make standard malloc/free calls independently of DSP/BIOS constraints.

-Jeff

Jeff Brower said:

That does not match Mariana's info above, which indicates that malloc() and MEM_alloc() co-exist and do not use overlapping areas.

I think there is some confusion as to what was meant by overlapping, in a typical BIOS application a call to malloc() is a call to MEM_alloc() with the section you define in the BIOS configuration file, see page 272 (second paragraph) of SPRU403o, as well as section 2.6 of SPRU423f. If you mean overlap as in conflict than they do not as they are the same, so they do co-exist depending on how you look at it.

Jeff Brower said:

MEM_alloc has disadvantages also, such as not being callable from an SWI_posted code.  Is there some way to avoid the override and access the standard C lib malloc?   I wonder if we could pull it out of the library .src code and use as needed.   It would be advantageous to be able to create and control a heap section and make standard malloc/free calls independently of DSP/BIOS constraints.

By my understanding the standard RTS malloc is not supported within BIOS, as mentioned in SPRU423f mentioned above, or at least it is not suggested to be used, I suspect if you had that linked in you would end up with conflicts depending on the circumstances. The RTS source can be found in C:\CCStudio_v3.3\C6000\cgtools\lib\rts.src (just a big text file), you could try extracting it out of there and working that way, but that is not something I have seen done before with malloc.

Bernie-

Bernie Thompson said:

By my understanding the standard RTS malloc is not supported within BIOS, as mentioned in SPRU423f mentioned above, or at least it is not suggested to be used, I suspect if you had that linked in you would end up with conflicts depending on the circumstances. The RTS source can be found in C:\CCStudio_v3.3\C6000\cgtools\lib\rts.src (just a big text file), you could try extracting it out of there and working that way, but that is not something I have seen done before with malloc.

We went ahead with the "create an independent mem management library" method, keeping it separate from DSP/BIOS mem management.  A few edits to the .src code and it started to work, and the final result exceeds my expectations.   A .sysmem section is visible in the .map file, shown as completely used and not available to "other" code.  We have the following advantages:

  -can call malloc / mfree from SWI_posted code

  -looks and feels like standard C lib mem management,
   no lock/unlock or other constraints -- easy to document
  and explain what's happening in the code

  -co-exists with DSP/BIOS MEM_xxx functions

  The first advantage is especially beneficial -- we can do very fast mem alloc and de-alloc, for example for real-time code such as jitter buffer, with no context switch required.

-Jeff

I am glad to hear that it works, and it sounds like it was not too much effort to extract the functionality from the RTS. Hopefully future users who have this need can follow in your footsteps, trying to malloc memory from a SWI or HWI is actually a common issue, usually customers have gotten around this by adjusting their application flow so that the call can be made from a task, but your work here can help those who need the call faster from anywhere, thank you for posting your results.