• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Embedded Software » BIOS » BIOS forum » MEM_alloc and MEM_free or new and delete?
Share
BIOS
  • Forum
  • Announcements
Options
  • Subscribe via RSS

MEM_alloc and MEM_free or new and delete?

MEM_alloc and MEM_free or new and delete?

This question is answered
Tim James
Posted by Tim James
on May 19 2010 10:52 AM
Prodigy150 points

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 

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Mariana
    Posted by Mariana
    on May 19 2010 11:12 AM
    Verified Answer
    Verified by David Friedland
    Mastermind24340 points

    Tim James
    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 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 James
    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!

    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.
    --------------------------------------------------------------------------------------------------------- 

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use