<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Unable to understand &amp;quot;init_mempool&amp;quot;, &amp;quot;malloc&amp;quot;, etc functions</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/24174/unable-to-understand-init_mempool-malloc-etc-functions</link><description> 
Hello, 
I am using Keil uVision3 V3.55 for Si-labs C8051F02X series. I am
using &amp;quot;init_mempool&amp;quot; function, so that I can use the functions like
&amp;quot;malloc&amp;quot;, &amp;quot;free&amp;quot;, etc. 
Here is my source code -- 

 
#include&amp;lt;c8051f020.h&amp;gt;
#include&amp;lt;stdlib.h&amp;gt;
void main(void</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/101833?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 21:51:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7ba75807-b09c-4547-bb21-31da2734c84c</guid><dc:creator>Heramb Phadke</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks to all, for their valuable suggestions.&lt;/p&gt;

&lt;p&gt;
The intension behind allocating only 15 bytes of memory is that,
to learn &amp;#39;malloc&amp;#39;, &amp;#39;calloc&amp;#39;. I have used these functions in C(by
using compilers like &lt;b&gt;Turbo C&lt;/b&gt;). But, in case of 8051, I wanted
to know, how do these functions work.&lt;/p&gt;

&lt;p&gt;
Thanks once again.&lt;/p&gt;

&lt;p&gt;
Regards,&lt;br /&gt;
Heramb Phadke&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/89741?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 08:23:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cc9164c1-a79d-42c7-ae10-43b9cb4ce60a</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
In this case, the second malloc call returned 0x09. The heap
started at 0x05, and the heap consumed four bytes fixed overhead.
0x05 + 4 =&amp;gt; 0x09, i.e. the lowest possible return address from
malloc() in your case - if we also ignores the NULL pointer you did
chose to ignore.&lt;/p&gt;

&lt;p&gt;
With the 4 bytes of static overhead, a 15 byte heap would have 11
bytes available to allocate from. And since each allocated block
needs one pointer and one block size, I would guess that the best
possible allocation from this tiny heap would be 11-4 = 7 bytes.
Using a 15 byte large heap just to manage a single 7 byte allocation,
while at the same time reducing the possible addressing modes
available to the compiler is not a good tradeoff.&lt;/p&gt;

&lt;p&gt;
There are some few situations where a heap may be good to have in
an 8051 processor. Most of the time, malloc() usage in a 8051 program
is a sign of an incorrect software design. The biggest reason for
Keil to supply malloc() is probably that less informed customers
shopping for a compiler expects the compiler to support malloc().&lt;/p&gt;

&lt;p&gt;
Whenever the application releases memory in a random order
compared to the allocations, and constantly allocates new data
without ever releasing everything, you will have big problems with
memory fragmentation that may make allocations fail even when there
are a lot of memory free on the heap.&lt;/p&gt;

&lt;p&gt;
This problem goes away if all blocks have a fixed size - but then
you could replace malloc() with a better alternative, and possibly
use a bitmap to keep track of free block.&lt;/p&gt;

&lt;p&gt;
A solution where blocks are always released in the reverse order
of the allocations would also work well - but that would basically be
a stack, in which case you can implement a custom solution that is
faster and with less memory overhead.&lt;/p&gt;

&lt;p&gt;
A solution where allocations happens only on startup is also free
from fragmentation problems. But then there would not be a need for
malloc(). It would be enough with one big array of memory, and then
just step one pointer forward n steps for each n byte allocation.
Much less code, and only the size of this pointer as RAM overhead.
Zero RAM overhead if the pointer is reused after the startup code has
performed the allocations.&lt;/p&gt;

&lt;p&gt;
When you really do need random allocations of blocks of varying
size, you may need to use add a second indirection, allowing the
allocation routines to store a pointer/offset to each allocated
block. Then you could regularly compact the heap, as long as you
don&amp;#39;t an interrupt to do an indirection while the compactation is
being done.&lt;/p&gt;

&lt;p&gt;
But in the end, malloc() really is a concept intended for
environments with infinite RAM or where you can accept a failed
allocation.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/56068?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 07:50:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6b199b4c-a6ae-43c8-80b7-003e55bb0df8</guid><dc:creator>Jon Ward</dc:creator><description>&lt;p&gt;&lt;p&gt;
Your call to init_mempool:&lt;/p&gt;

&lt;pre&gt;
init_mempool(0x05,15);
&lt;/pre&gt;

&lt;p&gt;
allocates only 15 bytes of memory. That&amp;#39;s an awfully small memory
pool. There is some overhead (a few bytes for the block size and a
pointer to the next free block) associated with each block allocated
from the pool. So, a pool that&amp;#39;s only 15 bytes long isn&amp;#39;t going to
hold much. Typically, the memory pool should be 1K or larger to
really be useful. Allocating only 15 bytes doesn&amp;#39;t require dynamic
memory to do.&lt;/p&gt;

&lt;p&gt;
See more information here: &lt;a href="http://www.keil.com/support/man/docs/c51/c51_init_mempool.htm"&gt;http://www.keil.com/support/man/docs/c51/c51_init_mempool.htm&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;
Jon&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/89747?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 07:33:30 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:65af1205-8e94-41e0-b428-9f986645ee43</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;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.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
the &amp;#39;51 is &lt;b&gt;singularily unsuited&lt;/b&gt; for malloc etc, DO
&amp;quot;Consider the advantages of using static allocations instead&amp;quot;.&lt;/p&gt;

&lt;p&gt;
since you need the heap to be big enough to hold the max size of
the array, why not just allocate the max.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;

&lt;p&gt;
&amp;quot;the &amp;#39;51 ain&amp;#39;t no PC&amp;quot;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/125449?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 03:59:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a1b8b597-9e80-4d3f-98ee-b6742943438e</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
Nowhere near supporting 15 bytes of allocation from a 15 byte
large heap, i.e. assuming that the heap has zero overhead.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/114910?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 02:28:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3f22da0e-0d82-4fc0-8338-760910d1fc3d</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
In this particular case, the source is provided:&lt;/p&gt;

&lt;p&gt;
&lt;a href="http://www.keil.com/support/man/docs/c51/c51_ap_memalloc.htm"&gt;http://www.keil.com/support/man/docs/c51/c51_ap_memalloc.htm&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/103104?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 02:12:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ff3bfbc5-db5a-4720-a04c-cf2f728dba1d</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Not sure - it is quite uncommon for the RTL manuals to mention the
overhead inside a heap manager.&lt;/p&gt;

&lt;p&gt;
A heap is something you normally use when you don&amp;#39;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.&lt;/p&gt;

&lt;p&gt;
The compiler vendors are free to change the implementation
whenever they like, so any code that can&amp;#39;t see the heap
implementation as a black box should stay away from it in the first
place.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/89749?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 01:58:59 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d08e1256-ca59-40c5-956c-9d5191ed0ad8</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
The overheads required by the default Keil implementation are
described in the &lt;b&gt;Manual&lt;/b&gt; - aren&amp;#39;t they...?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unable to understand "init_mempool", "malloc", etc functions</title><link>https://community.arm.com/thread/56074?ContentTypeID=1</link><pubDate>Wed, 13 May 2009 01:30:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4ec85907-692d-4e7d-bfa1-753bb508b40f</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Haven&amp;#39;t you thought about the possibility that the first malloc()
does not allocate anything - but returns a NULL?&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;

&lt;p&gt;
How large heap do you allocate - and how much data to you expect
to be able to fit?&lt;/p&gt;

&lt;p&gt;
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.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>