Amir Hadzic
Member
Hi!
I'v created this topic last night and while playing with the code I noticed that I can't use the new keyword to allocate pointers. I can't check the correct erros, I'm at work now but it was something about undefined references to _exit, _getpid or something like that.
Thank you!
mbolivar
LeafLabs
Hi Amir,
You are correct, dynamic memory allocation is not supported (Arduino doesn't have it, either) -- and on a board with only 20K RAM, it might not really be what you want!
Are you sure you need to dynamically allocate memory? Perhaps for your application, statically allocating the object you need will work.
RichardE
Member
Arduino 1.0 does now support dynamic memory allocation. You could argue that dynamic memory allocation is more important than ever on a device with limited memory. It means you can re-use the memory more easily at different points in your program. Without it your variables waste memory even when not being used.
Slightly disappointed this isn't supported.
gbulmer
Moderator
RichardE - It is quite unusual for embedded programs to use dynamic memory.
I strongly agree dynamic allocation and garbage collection are very useful and valuable features, but I don't agree that it is more important when RAM is scarce.
The main problems are:
1. It is extremely hard to test a program of even moderate complexity, and know that under all circumstances it will not run out of memory and break. Dynamic allocation makes this worse than simple static allocation and stack frames. This is a 'show stopper' for some developers.
2. Having managed memory can consume quite a lot of RAM in various overheads or fragmentation. This waste can be in the form of management overhead (which is needed to be able to manage memory), 'internal' fragmentation, and 'external' fragmentation.
Typically the smallest block that can be managed is some minimum-size because it needs to have a pointer to other blocks (4 bytes), and extra management typically the size of the block. The size must be held somewhere, so the correct size of block can always be recovered by free. Maybe we limit this to a 2 bytes. So say 6 bytes are used in every block of memory for management. Not too bad if user-objects are large, but very bad if user-objects are small.
The block might need to be aligned for the worst case data type (maybe an 8 byte double), which may make it impossible to use blocks smaller than 8 bytes.
To make things easier to manage, it is common to allocate memory in multiples of minimum-size. So if the whole block isn't full, the space is wasted. If the minimum block size were 8-bytes, then, on average 4 bytes would be wasted. That is 'internal' fragmentation - there is unused space, but you can't give it to the user's program because it can't be managed.
As blocks are freed, and then reallocated in random patterns, free space will appear between the other blocks which are in use. In languages like Java or Python, this can be solved, because the Java/Python VM could move the used blocks around to collect together the unused space. Normally in C or C++, those used blocks can't be moved. So there may be enough total free space to satisfy a new request, but because it is fragmented by in-use blocks, the request can't be satisfied. That type of wasted space is often called external fragmentation.
Summary:
1. It is hard to test programs and know memory fragmentation will not cause them to fail
2. Memory management and garbage collection have overhead, and can't always make good use of RAM dues to fragmentation.
HTH
RichardE
Member
I take your point. It is hard to do and there are certainly dangers of memory leaks, but I still think that beyond a certain minimum RAM size dynamic memory allocation is important and becomes less important as the RAM size increases.
The program I am working on at the moment is an example. You could argue that this is not an embedded program at all. I started on the Arduino with a Gameduino shield (truly awesome shield which works fine with the Maple - buy one even if you have no intention of writing games) and started writing a clone of the Robotron arcade game. It went very well. Every level has a number of enemies that can be of a number of different types. All enemies are implemented as classes derived from a common base class (EnemyObject). At the start of every level you read counts for the number of enemies of each type and then dynamically allocate memory for each enemy. When the level ends you delete all the enemies freeing up memory so the next level can re-use it.
Eventually, even sticking as much as possible in program memory, RAM started to get a bit tight (Arduino only has 2K) so I bought a Maple and started porting the code. Then I realised there was no dynamic memory allocation. The simplest way around this is to declare arrays containing all the enemies you will need, for all levels but this is staggeringly wasteful. Suppose you are allowed a maximum number of 10 enemies of a particular type on each level. Then you need 10 arrays with 10 of enemy type A, 10 of enemy type B, 10 of enemy type C and so on. These are occupying RAM all the time, even when no enemies of a particular type appear in a level so you are bound to run out of memory sooner rather than later.
Eventually I got around this by allocating memory on the stack. Each level is a class with a PlayLevel method. The PlayLevel method creates a lot of enemy arrays as *local* variables and then calls a method in a base class that runs around the game loop until the level ends, passing these enemy arrays to the method. When the level ends and PlayLevel finishes all the array vanish as they are local variables. It works, but it is rather cumbersome and in the end I had to write a C# program to generate the source code for each level. It would be so much easier if I could allocate memory dynamically.
mbolivar
LeafLabs
RichardE:
Dynamic memory should work as of v0.0.12. Can you present a program that doesn't work as expected?
Edit: Fix typo. Also see: http://leaflabs.com/docs/faq.html#how-can-i-use-malloc-new
shark2600
Member
Hi mbolivar,
I'm using v0.0.12, the 'new' and 'delete' operators still not working. I have to put dummy _exit, _kill and _getpid() in syscalls.c to get them work, any suggestion?
FYI: I added the following to \maple-ide-0.0.12-windowsxp32\hardware\leaflabs\cores\maple\syscalls.c to get new and delete work.
The reason why I need this is I need stl::vector and so on support in my project.
Thanks
/*
* getpid -- only one process, so just return 1.
*/
#define __MYPID 1
int _getpid()
{
return __MYPID;
}
/*
* kill -- go out via exit...
*/
int _kill(int pid, int sig)
{
return -1;
}
int _exit(int val)
{
return (-1);
}
mbolivar
LeafLabs
Thanks for the report. I've never tested the STL classes, so it's good to know you got vector working.
Just guessing, but it sounds like the issue isn't with new/delete, but that the std::vector constructor or destructor is calling those routines, which we don't provide by default.
mbolivar
LeafLabs
You're absolutely right. Strange; I swear this was working for v0.0.12; we used it in the Maple Native guitar effects demo.
In any case, this was fixed in libmaple c4e0847 by adding an abort() implementation. You can either take that approach, or just use your workaround. The fix will be part of the next release.
Sorry for the mistake.
You must log in to post.
