malloc and friends

The idea of either recursive function calls _or_ using the heap in normal run-time code in an embedded system gives me the heebi-jeebies. Can you say "stack overflow" and "fragmented heap" (think "embarrassing or dangerous crash").

Simple mallocs are easy to write and fun. Just make a linked list of blocks, each one with a header that has a pointer to the next block and a length. Compared to fast mallocs and leak-detecting mallocs and other sorts of things it'll be dumb as a post, but it'll get the job done as long as speed isn't an issue.

I googled for "simple malloc" and came up with this as the 1st hit:

Looks like a source code for a simple malloc to me... ;)

A word of caution: You do not want to use traditional malloc routines on a processor with no memory manager. But it looks like you've figured that one out.

G.

It sure is.....at least today it is.......last night it was 404. I looked before crying for help, honest I did. ;-) Thanks, I have a copy of it now.

This is nothing critical, just some tinkering and trying to learn something new. ;-) After having some coffee, I've rethought the problem and solved it without malloc. In the future, I'm sure that I will make use of the code I downloaded from the above link, thanks again.

Just tinkering here at home, nothing critical. :-) I drank some coffee and thought about it for a bit and decided to do things a different way. The nature of the problem, makes it easy to just use a simple char array. I do still want something like malloc and I will probably use the code that "G" pointed me to as a starting platform for my own.

Thanks :-)

... snip ...

I have two points of disagreement. First is with the dangers in embedded - those depend on the uses to which you put malloc and friends.

Second is on the complexity. My version of malloc (nmalloc.zip) depends on 1) Linear addressing, i.e. one big segment addressed by byte 2) sbrk system call and 3) use of GCC to compile. With those restrictions I believe it to be as portable as is possible.

I just measured the resultant object code. Including malloc, realloc, free, and calloc the code comes to just over 3000 (decimal) bytes for the 80x86. All operations are O(1), so you will never be hung up waiting for something long to happen. (calloc was added fairly recently due to some possible low-odds systematic problems, and may not be in the version published.)

The gcc compilation restriction is because of debug macros embedded, which will not quietly disappear on other compilers (they use gcc specific variadic macros). Thus compilation on other systems may require source rework.

If the published version is earlier than 2007-01-28 it does not include the calloc segment mentioned above, but the remainder of the code is unchanged. Using this code you will have various leak detection etc. stuff available (see malldbug in the nmalloc.zip package).

You can find the (free of restrictions) source at:

BGET Memory Allocator:

Leo Havmøller.