I've been given a 8051 based board with an embedded in-house operating system. I am using SDCC to create applications above the OS. And malloc is not available so I have to allocate memory statically. Why is that? Isn't malloc supposed to be on a dynamic library within the compiler?
Asked
Active
Viewed 785 times
3
-
1Relevant reading material https://stackoverflow.com/questions/30825151/is-there-a-meaningful-distinction-between-freestanding-and-hosted-implementation – StoryTeller - Unslander Monica Sep 12 '18 at 12:53
-
1You can't allocate what doesn't exist... – M.M Sep 12 '18 at 12:53
-
4No. `malloc` is part of the standard library and not part of the compiler. So your board must provide a library that implements malloc. – Paul Ogilvie Sep 12 '18 at 12:53
-
3On systems with very little RAM, dynamic memory allocation doesn't make much sens most of the time. – Jabberwocky Sep 12 '18 at 12:54
-
It wasn't uncommon back in the old console days (PS2 and earlier) to allocate all of the memory from the OS at startup and then just use memory by address for your game from a manually created memory map in a spreadsheet. – Retired Ninja Sep 12 '18 at 13:27
-
If it would make your life easier, you can reserve a chunk of memory and write a simple `malloc` and `free` to manage that chunk. – Paul Ogilvie Sep 12 '18 at 14:22
-
@PaulOgilvie returning an 8-bit pointer to an array of bits? :) – Martin James Sep 12 '18 at 15:35
-
1@PaulOgilvie *board*, really? – unalignedmemoryaccess Sep 12 '18 at 15:38
3 Answers
8
TL;DR:
Why and when malloc() will not be available in C?
The only thing that can be said in general is that malloc() will be provided by every conforming, hosted C implementation, but there are other kinds, including another conforming kind.
Isn't malloc supposed to be on a dynamic library within the compiler?
Not exactly. malloc() is part of the C standard library, therefore it is provided by every conforming, hosted C implementation. A C implementation comprises a system for translating C source code into executable programs and a mechanism and environment for running the resulting programs. The former typically revolves around a compiler. The latter includes as much of the C standard library as the implementation provides, and this part is where malloc resides if it is available. Thus, no, malloc is technically not part of the compiler.
I'm sure that's not a distinction you meant to invoke, but it does bear on the answer. Note well that I said that malloc is provided by hosted implementations. These are the kind you ordinarily run into on general-purpose operating systems. They create programs that are launched in a standard way via the host OS, and they provide all the features of the C standard library in conjunction with the OS. But there are also freestanding implementations. One of the key differences is that freestanding implementations are excused from providing most of the standard library, including malloc().
You will commonly find freestanding implementations in use for and on embedded systems, such as yours. They are also used for OS kernels, boot loaders, and other such programs than run directly on bare metal. That your programs run on top of an OS makes your environment a bit of a Cadillac among embedded systems, but does not ensure that the C implementation is a hosted one. Inasmuch as it does not provide malloc, it cannot be a conforming hosted implementation, but it can be a conforming freestanding implementation. It ought to document which, if either, it claims to be. If it is freestanding but provides other standard library functions then you can consider that a luxury.
John Bollinger
- 160,171
- 8
- 81
- 157
-
@cleveraintwise, no, unless the implementation claims to be a conforming, hosted implementation, it is not safe to assume that `malloc()` will be available to programs in the execution environment. Period. There is *no* library function that the C standard requires standalone implementations to provide, not even `malloc()`, and the standard makes no demands at all on non-conforming implementations. There is no substitute for reading your implementation's documentation, at least enough to check whether it claims to be a conforming, hosted one. – John Bollinger Sep 12 '18 at 19:21
-
-
1@cleveraintwise, without any documentation at all, you have no basis at all for what code you can or should write. Even if "documentation" means word of mouth from the person responsible for the C implementation, you have to have *something* in order to do any work. – John Bollinger Sep 12 '18 at 20:13
-
Addendum: absence of documentation technically makes the implementation non-conforming in any case, because conforming implementations of either kind are required to document their choices for a variety of *implementation defined behaviors*. – John Bollinger Feb 10 '22 at 23:00
2
Some guidelines for (safety) critical systems does not allow dynamic memory allocations.
For example MISRA C:2004 guideline have the following rule:
20.4 - Dynamic heap memory allocation shall not be used.
One way to follow the rule is: Don't bring or implement malloc() and other dynamic memory allocation functions to the system.
Those kind of systems are typically embedded systems, where memory needs are well known/limited during or before compile time. So dynamic memory allocations can be avoided without pain.
SKi
- 8,007
- 2
- 26
- 57
-1
With C libraries included in your project you can leverage the functions like malloc, printf....etc Understand that 8051 is a low memory foot print device in order of few KB. Hence inclusion of C libraries would increase the size of output .hex file and you will run out of memory.
Javeed Shariff
- 52
- 3
-
The problem is RAM. Unless there is XDATA space,. malloc() etc. is umm... 'best avoided' on 8051. – Martin James Sep 12 '18 at 15:31
-
Actually even if there is XDATA RAM, malloc() etc. is umm... 'best avoided' on 8051. – Martin James Sep 12 '18 at 15:32
-
4In fact, avoiding the 8051 altogether is not an unreasonable approach;) – Martin James Sep 12 '18 at 15:33