> >----- Ursprüngliche Nachricht ----- >Von: Sergio Campamá >Gesendet am: 22 Aug 2011 13:36:07 > > > So the problem is not really malloc, but > free Interesting I'll give that a look. Thanks! > >Actually, it's the way malloc/free works. >Putting a nail neatly into a tire doesn't give >you a flat tire. But if you pull it out again... > >Using only malloc does just waste a few bytes >(at least two, depending on implementation) >for organizational issues. >In this case an plain incremental malloc that >just keeps the address of the first unused byte >on the heap would be way more effective (and >faster). But you could never free ram again. >However, malloc does offer freeing ram and has >to keep the overhead, even if you don't use it. >Moreover, it needs to follow the chain of >malloced areas to find the first free one. Which is >(relatively) slow. >And I doubt the MSP implementation has an >algorithm to search for the best fitting hole, >using the first that is large enough. Which >increases heap congestion for different-sized >mallocs. > >However, a plain malloc version should be easy >to implement yourself. Just start using >ram where the last variable ends, and keep a >pointer to the first unused byte. (which is >the pointer to the first byte of the next allocated space) >No need to link malloc/free anymore, making your code smaller too.
This is actually the most common implementation I've seen on microcontrollers. For a big project I also needed to free memory. Because fragmentation is always a problem I created a linked list with small memory blocks and functions to create, delete, read and write these blocks sequentally. The interesting thing about this method is that fragmentation is no longer a problem. And because you can process buffers in small chunks (freeing what is already read) it doesn't require a large processing buffer. I also added malloc, realloc and free to this system to be able to allocate contiguous pieces of memory. For this purpose I had to use a seperate array to keep track of the blocks. To speeds things up I kept a pointer to the next free piece of memory and a counter to keep track of the amount of memory in use / free. In most cases I prefer to use the stack to store data because allocation and freeing are handled by the compiler. All this however does not solve the problem of running out of memory. You'll need to carefully plan memory consumption to ensure you'll not run out. Nico Coesel ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
