Re: [avr-libc-dev] Port and Memory Mapped Register Definitions

[Joerg Wunsch]

As Bill Somerville wrote:

> I've got versions of new, delete, new_handler, set_new_handler that I
> use, I'll tidy them up and post them here - they are pretty short and
> simple as they just delegate to malloc() and free().

That's what i would have expected anyway.

> I'm not sure of the
> position with exceptions (which is related) with avr-g++, I havn't tried
> them - I see the compiler turns them off by default. I expect the
> overhead maybe too much for the smaller acrhitectures. Has anyone tried
> code with exceptions?

There are two problems.  Yes, the overhead is tremendous.  I've been
shocked when i compiled a simple C++ test class and saw how much code
it ate up until i noticed the bloat was caused by the exception
handling.  Effectively, i think you can only afford it on an ATmega128
(or larger) to use them at all (and even then, it'll cost run-time as
well).

Second, when enabling exceptions (which used to be the default), the
linker will attempt to link __gxx_personality_sj0() which looks to me
like a default exception handler or somesuch.  Since this function is
part of libstdc++ (which we can't build at all since the code grows
beyond any useful limits for the AVR), linking will fail.

Sorry, my rudimentary C++ knowledge ends right before the concept of
exceptions ;-) (and only contains even more rudimentary ideas about
how to create templates), thus i've got no idea about what this
function is actually trying to do.

If you want exceptions to work, you'll probably need to port this
function.  We could include it in our supplied version of libstdc++ as
well if people think exceptions are worthwhile to support, although
i'd prefer if we could keep our libstdc++ away from (L)GPL if possible
(which however would mean to completely rewrite this function from
scratch).  Our target user group consists of many people working with
embedded systems where the implications even of LGPL (the requirement
to supply .o files to the end users) are mostly not desirable.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/