[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/
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], (continued)
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/13
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Joerg Wunsch, 2003/06/14
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Joerg Wunsch, 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Russell Shaw, 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Russell Shaw, 2003/06/15
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/16
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.],
Joerg Wunsch <=
- Re: [avr-libc-dev] Deprecation policy [was: Re: [RFC][PATCH] Deprecate inb / outb.], Dmitry K., 2003/06/18