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

[Joerg Wunsch]

As Theodore A. Roth wrote:

> :) It appears that outb() and inb() always use memory mapped i/o ports
> :) rather than registers if possible - is this true and if so why?
> 
> Hmmm. I don't have a clue. Marek reimplemented these using the _SFR_*
> mechanism, so that might have something to do with it.

See

http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/group__avr__sfr.html

While the generated code initially /looks/ like using the mmio
approach, the compiler's optimization will normally turn this into
IN/OUT instruction wherever possible.  Note that some extended IO
registers on the larger ATmegas cannot be reached using IN/OUT at all
though.

> :) The setjmp.h header file is not C++ compatible (no extern "C++"
> :) declaration), is this deliberate?
> 
> I don't know the history on this, but I don't see any harm in fixing it.
> I'll fix it, but I would like to know if the jmp_buf struct definition
> needs to be protected too?

Structs don't need to be protected, the only difference is that
"struct foo" in C++ introduces the scope-wide identifier "foo", while
in C it only introduces the scope-wide identifier "struct foo" (i. e.,
you can still use "foo" for something else).

> I assume you're talking about a "watered down" version of libstdc++
> for avr? I'm not against it, but I don't have the know-how to do.

I'm in favour for such an approach.  We could easily integrate it into
the avr-libc project, as a new subdir libstdc++, used to generate a
third library libstdc++.a.  Once we've got it, we can revert avr-gcc's
specs to use -lstdc++ instead of -lc.

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