tags:

views:

1274

answers:

12

I am writing C for an MPC 555 board and need to figure out how to allocate dynamic memory without using malloc.

+1  A: 

malloc() and its related functions are the only game in town. You can, of course, roll your own memory management system in whatever way you choose.

Carl Norum
+14  A: 
asveikau
I get the vibe from the question that @patrick isn't using a full-fledged OS, or memory allocation would already be working for him.
Carl Norum
In that case, you'd be looking at statically allocating a huge buffer and managing that yourself.
Anon.
Good observation, Carl. I put a <strike> around my old answer and wrote a different suggestion.
asveikau
dlmalloc assumes a POSIX operating system environment, specifically, by making calls to sbrk() and mmap(). It is unclear whether the OP may utilize an sbrk() function. The absence of malloc implies the possibility that sbrk() is disallowed.
Heath Hunnicutt
@Heath Hunnicutt - It's been a while since I've looked at it, but IIRC dlmalloc has comments that say something along the lines of, "rewrite this part to provide `morecore` type functionality". Doing this is probably simpler than writing a new malloc.
asveikau
@asveikau - Doing so probably would be simpler than writing a new malloc. There are other alternatives, such as not implementing malloc(), but rather a dynamic allocator suitable for his purpose and yet not conformant to malloc() API. If dlmalloc were a 'drop in' solution, that would solve his problem. Depending on his requirements, which OP hasn't fully explained, dlmalloc might be good enough.
Heath Hunnicutt
+1 for providing links to source.
alesplin
+3  A: 

If your runtime doesn't support malloc, you can find an open source malloc and tweak it to manage a chunk of memory yourself.

GregS
+2  A: 

malloc() is an abstraction that is use to allow C programs to allocate memory without having to understand details about how memory is actually allocated from the operating system. If you can't use malloc, then you have no choice other than to use whatever facilities for memory allocation that are provided by your operating system.

If you have no operating system, then you must have full control over the layout of memory. At that point for simple systems the easiest solution is to just make everything static and/or global, for more complex systems, you will want to reserve some portion of memory for a heap allocator and then write (or borrow) some code that use that memory to implement malloc.

John Knoeller
+1  A: 

Write your own. Preallocate a big chunk of static RAM, then write some functions to grab and release chunks of it. That's the spirit of what malloc() does, except that it asks the OS to allocate and deallocate memory pages dynamically.

There are a multitude of ways of keeping track of what is allocated and what is not (bitmaps, used/free linked lists, binary trees, etc.). You should be able to find many references with a few choice Google searches.

Loadmaster
+2  A: 

You should explain why you can't use malloc(), as there might be different solutions for different reasons, and there are several reasons why it might be forbidden or unavailable on small/embedded systems:

  • concern over memory fragmentation. In this case a set of routines that allocate fixed size memory blocks for one or more pools of memory might be the solution.
  • the runtime doesn't provide a malloc() - I think most modern toolsets for embedded systems do provide some way to link in a malloc() implementation, but maybe you're using one that doesn't for whatever reason. In that case, using Doug Lea's public domain malloc might be a good choice, but it might be too large for your system (I'm not familiar with the MPC 555 off the top of my head). If that's the case, a very simple, custom malloc() facility might be in order. It's not too hard to write, but make sure you unit test the hell out of uit because it's also easy to get details wrong. For example, I have a set of very small routines that use a brain dead memory allocation strategy using blocks on a free list (the allocator can be compile-time configured for first, best or last fit). I give it an array of char at initialization, and subsequent allocation calls will split free blocks as necessary. It's nowhere near as sophisticated as Lea's malloc(), but it's pretty dang small so for simple uses it'll do the trick.
  • many embedded projects forbid the use of dynamic memory allocation - in this case, you have to live with statically allocated structures
Michael Burr
Doug Lea's public domain malloc, used in Linux, assuems a POSIX operating system environment. Specifically, dlmalloc makes calls to sbrk() and mmap(). It is unclear whether the OP may utilize an sbrk() function.
Heath Hunnicutt
+1  A: 

An answer really depends on why you might need to dynamically allocate memory. What is the system doing that it needs to allocate memory yet cannot use a static buffer? The answer to that question will guide your requirements in managing memory. From there, you can determine which data structure you want to use to manage your memory.

For example, a friend of mine wrote a thing like a video game, which rendered video in scan-lines to the screen. That team determined that memory would be allocated for each scan-line, but there was a specific limit to how many bytes that could be for any given scene. After rendering each scan-line, all the temporary objects allocated during that rendering were freed.

To avoid the possibility of memory leaks and for performance reasons (this was in the 90's and computers were slower then), they took the following approach: They pre-allocated a buffer which was large enough to satisfy all the allocations for a scan-line, according to the scene parameters which determined the maximum size needed. At the beginning of each scan-line, a global pointer was set to the beginning of the scan line. As each object was allocated from this buffer, the global pointer value was returned, and the pointer was advanced to the next machine-word-aligned position following the allocated amount of bytes. (This alignment padding was including in the original calculation of buffer size, and in the 90's was four bytes but should now be 16 bytes on some machinery.) At the end of each scan-line, the global pointer was reset to the beginning of the buffer.

In "debug" builds, there were two scan buffers, which were protected using virtual memory protection during alternating scan lines. This method detects stale pointers being used from one scan-line to the next.

The buffer of scan-line memory may be called a "pool" or "arena" depending on whome you ask. The relevant detail is that this is a very simple data structure which manages memory for a certain task. It is not a general memory manager (or, properly, "free store implementation") such as malloc, which might be what you are asking for.

Your application may require a different data structure to keep track of your free storage. What is your application?

Heath Hunnicutt
A: 

If there are issues allocating dynamic memory from the heap, you can try allocating memory from the stack using alloca(). The usual caveats apply:

  • The memory is gone when you return.
  • The amount of memory you can allocate is dependent on the maximum size of your stack.
Vector Maniac
+1  A: 

Write your own. Since your allocator will probably be specialized to a few types of objects, I recommend the Quick Fit scheme developed by Bill Wulf and Charles Weinstock. (I have not been able to find a free copy of this paper, but many people have access to the ACM digital library.) The paper is short, easy to read, and well suited to your problem.

If you turn out to need a more general allocator, the best guide I have found on the topic of programming on machines with fixed memory is Donald Knuth's book The Art of Computer Programming, Volume 1. If you want examples, you can find good ones in Don's epic book-length treatment of the source code of TeX, TeX: The Program.

Finally, the undergraduate textbook by Bryant and O'Hallaron is rather expensive, but it goes through the implementation of malloc in excruciating detail.

Norman Ramsey
I am confused by the link you posted. The code there seems to wrap malloc(), calloc() functions.
Heath Hunnicutt
@Heath: I was the one confused. In fact, total brain cramp. I was thinking of something else Hanson had written that did not make it into the book.
Norman Ramsey
A: 

You might be interested in: liballoc

It's a simple, easy-to-implement malloc/free/calloc/realloc replacement which works.

If you know beforehand or can figure out the available memory regions on your device, you can also use their libbmmm to manage these large memory blocks and provide a backing-store for liballoc. They are BSD licensed and free.

durand
liballoc states that it requires a "standard UNIX environment" which it seems the OP does not have. I imagine liballoc calls sbrk() and mmap().
Heath Hunnicutt
liballoc doesn't require much. It requires a way to allocate pages of memory(*very* trivial to implement a page manager). mmap and sbrk has nothing to do with it.
Earlz
+1  A: 

You might want to check out Ralph Hempel's Embedded Memory Manager.

Dan
A: 

FreeRTOS contains 3 examples implementations of memory allocation (including malloc()) to achieve different optimizations and use cases appropriate for small embedded systems (AVR, ARM, etc). See the FreeRTOS manual for more information.

I don't see a port for the MPC555, but it shouldn't be difficult to adapt the code to your needs.

adamjansen