[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Port and Memory Mapped Register Definitions
Date: Mon, 30 Sep 2002 16:30:17 +0200
User-agent: Mutt/1.2.5i

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.



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

> :) 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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]