Which compiler do you use to compile C++ for embedded apps?

Quintin Beukes



On Wed, Oct 14, 2009 at 9:48 PM, Bob Ammerman <rammerman@verizon.net> wrote:
> Careful use of dynamically allocated memory can make sense in an embedded
> application. As examples, I will document the way dynamic memory is used in
> three large embedded systems I have developed (one in assembler, one in C
> and one in C++) that all use carefully managed dynamic memory allocation. It
> is interesting to note that several techniques, as outlined below, can be
> used to avoid the twin bugaboos of fragmentation and memory exhaustion.
> Admittedly all of these systems have much more memory than a PIC.
>
> The assembler program always allocates memory in one page (256 byte)
> increments, larger structures are kept as linked lists of these pages. When
> memory runs out various caches are emptied and returned to the free memory
> pool. This is done by the memory allocator in a way that is transparent to
> the application. The design of the system is such that memory cannot be
> exhausted completely. This system is fragmentation proof (because all
> allocations are for the same size block), exhaustion proof (because cache
> data can always be returned to the free pool) and has run for years and
> years without trouble.
>
> The C program does most of its dynamic allocation at startup. The remaining
> allocations are handle-based and thus can be moved around in memory to avoid
> fragmentation. Again, memory exhaustion is avoided by returning
> least-recently-used data to the free pool. This system is fragmentation
> proof (because of the handle-based allocation), exhaustion proof (because
> lru data is returned to the free pool when needed) and has run for years and
> years without trouble.
>
> The C++ program is perhaps the most interesting. It uses a custom allocator
> so that "new" operations are always taken from one of several pools of
> memory, each of fixed size elements, thus making fragmentation impossible.
> In this case exhaustion is avoided by simply having more memory available
> (several megabytes) than a careful calculation of maximum usage (verified by
> 'worst case' testing to be less than a megabyte) shows is needed. [Note that
> I am not 100% happy with this, sometimes 'worst case' isn't the worst case].
> Again, this program has run for many years.
>
> -- Bob Ammerman
> RAm Systems
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist