We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
Haven't you thought about the possibility that the first malloc() does not allocate anything - but returns a NULL?
Remember that the heap is a magic black box. The compiler may need an unknown overhead just to initialize the heap. And each malloc() may need overhead - either inside the allocated block, or in a fixed table/tree somewhere else in the heap.
How large heap do you allocate - and how much data to you expect to be able to fit?
Consider the advantages of using static allocations instead. This also allows the compiler the option to produce better code, since the address of your memory block will be known during compile/link time, instead of being determined at runtime.
The overheads required by the default Keil implementation are described in the Manual - aren't they...?
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.
In this particular case, the source is provided:
http://www.keil.com/support/man/docs/c51/c51_ap_memalloc.htm
Seems to be a quite traditional design. A bit of header information always consumed with at least a free list, and then each allocated block gets extended with a pointer and a size.
Nowhere near supporting 15 bytes of allocation from a 15 byte large heap, i.e. assuming that the heap has zero overhead.
the '51 is singularily unsuited for malloc etc, DO "Consider the advantages of using static allocations instead".
since you need the heap to be big enough to hold the max size of the array, why not just allocate the max.
Erik
"the '51 ain't no PC"