avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.]
Date: Wed, 18 Jun 2003 12:26:21 +0200
User-agent: Mutt/1.2.5i

As Dmitry K. wrote:

> > Basically, it's now no longer (easily) possible to use one
> > of the SFRs as the target of an inline asm statement anyway (see bug
> > ID #2233, we need to update our inline asm docs accordingly).
> 
> Examples of SFRs usage:

> /* Examples of SFRs as the target of an inline asm statements.
>    For qualitative realization it is necessary to add check:
>       if (__builtin_constant_p((port)))
>  */
> #define cbi_atomic(port,bit)    do {                    \
>     if (_SFR_IO_ADDR(port) < 0x20) {                    \
>         asm volatile (                                  \
>             "cbi  %0,%1"                                \
>             :                                           \
>             : "I"(_SFR_IO_ADDR(port)),                  \
>               "I"((unsigned char)(bit)) );              \
>     } else {                                            \

You need even a third alternative here, for the extended registers of
the ATmega128.

Anyway, the current cbi() implementation has been there for about a
year now, and so far you're the first to complain, and your complaint
has even only been triggered once it was treatened to deprecate the
existing sbi/cbi macros.  I don't wanna be the code czar here, but i
don't see much added value by providing just a workaround for those
who for some reason think they really need to work without
optimization.

As for the »atomic« operation (wrt. interrupt handling), that's a
completely different matter and doesn't only affect sbi/cbi but also
e. g. 16-bit IO.  There has been consensus here (when the 16-bit IO
was discussed) that it is best left to the application programmer to
save and restore SREG, as opposed to implying this in a foo_atomic
macro, for various reasons.  Among them are that the application
writer is the one to decide whether the overhead is really needed, as
well as possible situations like:

        sreg = SREG;
        cli();
        IOREG |= _BV(BIT);
        IOREG &= ~_BV(BIT);
        SREG = sreg;

where the foo_atomic macros would cause additional overhead and loss
of atomicness (between the bit set and clear) that might be desired.
If you really need a macro for this, something like the following
should usually work:

#define atomic(op) \
do { unsigned char __saved_sreg = SREG; cli();\
op; \
SREG = __saved_sreg; } while (0)

-- 
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]