This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable to understand "init_mempool", "malloc", etc functions

Hello,
I am using Keil uVision3 V3.55 for Si-labs C8051F02X series. I am using "init_mempool" function, so that I can use the functions like "malloc", "free", etc.
Here is my source code --

#include<c8051f020.h>
#include<stdlib.h>
void main(void)
{
unsigned char xdata  *ptr, *ptr1;
init_mempool(0x05,15);
ptr = malloc(10);
ptr1 = malloc(5);
         *ptr++ = 11;
        *ptr++ = 22;
        *ptr++ = 33;
        *ptr++ = 44;

         *ptr1++ = 1;
        *ptr1++ = 2;
        *ptr1++ = 3;

}


I am expecting that, all the above data to be put from the locations 0x05(in xdata) onwards. But, I found that "ptr1" points to 0x00(in xdata), and "ptr" points to 0x09(in xdata).
So, what is the role of "init_mempool" function here?
Why does "malloc" allocate memory from 0x00??

Thanks in advance,

Regards,
Heramb Phadke

Parents
  • Not sure - it is quite uncommon for the RTL manuals to mention the overhead inside a heap manager.

    A heap is something you normally use when you don't have to care about a minimum number of concurrent allocations - either because you have an almost infinite amount of memory, or because you can either let the program die or just fail a specific operation in case of an allocation failure.

    The compiler vendors are free to change the implementation whenever they like, so any code that can't see the heap implementation as a black box should stay away from it in the first place.

Reply
  • Not sure - it is quite uncommon for the RTL manuals to mention the overhead inside a heap manager.

    A heap is something you normally use when you don't have to care about a minimum number of concurrent allocations - either because you have an almost infinite amount of memory, or because you can either let the program die or just fail a specific operation in case of an allocation failure.

    The compiler vendors are free to change the implementation whenever they like, so any code that can't see the heap implementation as a black box should stay away from it in the first place.

Children