Memory Leakage

If you statically allocate, you don't need a heap!

You decide the size at compile time!

If you statically allocate, you don't need a heap!

You decide the size at compile time!

Hi,
You are right that i dont need the heap if i dont allocate memory dynamically. I just want to know how to assing the size of heap at compiler time ?

"I just want to know how to assing the size of heap at compiler time ?"

It's not really done at compile time. Look at where you called init_mempool(). One of its parameters is the size, so the size of the heap is as big as you made it!

http://www.keil.com/support/man/docs/c51/c51_init_mempool.htm

Thanks Neil.
If i ask the same question in a very generic way, means for any processor if i want to know the maximum heap memory available for my program in advance then whats the way for this ?

"If i ask the same question in a very generic way, means for any processor if i want to know the maximum heap memory available for my program in advance then whats the way for this ?"

There isn't one!

The 'C' language defines only 4 memory-management functions: calloc, free, malloc, and realloc - any others will be implementation-defined (and probably depend upon system calls to the environment).

The best you can do is write yourself a standard "wrapper" that makes the appropriate system call(s) based conditional-compilation.

BEWARE! you could get yourself into all sorts of trouble here due to the different alignment, etc, issues of different systems...

Thanks Neil and Dan for providing me useful information.

go get a pill that will cure your PCitis

the '51 aint no PC

Erik

Modify (or replace) the library implementation with a version that takes extra parameters. On malloc(), pass in an indicator of the call point. (__FILE__ and __LINE___ can be used; the strings will take up a lot of memory. You might have to substitute an enum to save space, at the cost of more typing.) The malloc implementation stores this information in its memory allocation overhead. Wrap your new function in a macro so that it looks like the regular call, if you can use the FILE/LINE method.

Now, after you run the program for a while, you can inspect the heap (either with your debugger, or by writing a debug function to help out). Ideally you can run the program to a point where all memory should be free, to avoid confusion. You'll be able to see the source file and line that allocated each block. This generally gives you a good hint as to who failed to deallocate the blocks.

There are commercial libraries that do exactly this for larger platforms. A general-purpose heap is unpopular enough on the 8051 that such may be hard to find, so you might have to roll your own.

Hi Eric,
I am not getting you.

linked lists, malloc, heap, ....

why do you not apply '51 programming practices instead of treating it as a PC.

If you took, just a few hours, and familiarized yorself with the architecture of the '51, you woud see that certain "common PC C practices" are almost deadly to the '51. In another thread you will see that writing "'51 friendly" C can reduce program size dramatically and at the same time increase throughput.

The "statement C is C on any device, you need not know what the device is capable of doing efficiently" is a blatant lie.

The '51 ain't no PC

Erik

"In another thread you will see that writing "'51 friendly" C can reduce program size dramatically and at the same time increase throughput"

Can you tell whats the "51 friendly" C ?

Can you tell whats the "51 friendly" C ?

http://www.keil.com/forum/docs/thread7148.asp

this, currently active, thread discuss it and Andy state in the 2nd post "Have you paid attention to the section in the Manual on writing optimum code?"

Erik