[En-Nut-Discussion] Removal of 8-bit AVR support (Re: STM32L051 and LPUART)

[Nathan Moore]

On Mon, Oct 31, 2016 at 6:02 AM, Uwe Bonnes <
bon at elektron.ikp.physik.tu-darmstadt.de> wrote:

> >>>>> "Nathan" == Nathan Moore <nategoose at gmail.com> writes:
>
>     Nathan> On Tue, Oct 25, 2016 at 5:19 AM, Uwe Bonnes <
>     Nathan> bon at elektron.ikp.physik.tu-darmstadt.de> wrote:
>
>     >>
>     >> Another thing is the protection of 2 and 4 byte variables with a
>     >> Critical section. This is not needed with 32-bit systems. But a look
>     >> at nut/dev/ shows that only the old u(s)art driver use it. So it is
>     >> legacy, but does not hamper us beside carrying old code around.
>     >>
>
>     Nathan> I started to write some Critical macros that would take a
>     Nathan> parameter to test for size and alignment to determine if they
>     Nathan> should actually do anything, but while doable in GCC that got
>     Nathan> complicated quickly.  Is that something that people would find
>     Nathan> useful?  Is that something that people would trust and/or use
>     Nathan> correctly?  Alternately, a family of Critical macros with size
>     Nathan> suffixes could be written for each architecture and not rely so
>     Nathan> much on the preprocessor and compiler to get it right.
>
> Did you have a look at the gcc atomic macros?
> https://gcc.gnu.org/onlinedocs/gcc-4.3.4/gcc/Atomic-Builtins.html
> and friends


I hadn't, but even though those are for Itanium the API might be
worth mimicking, as long as Intel doesn't care, since GCC got them
from Intel's ABI documentation for Itanium.  I was really just thinking
about EnterCritical and ExitCritical macros that either knew or were
told what size data they were protecting and compiled to no code
for 32 bit updates on 32 bit memory width architectures.
Having interfaces that actually encompassed the synchronization and
the work might make them easier to use, though.

Nathan