> -----Original Message----- > From: > avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Joerg Wunsch > Sent: Monday, March 23, 2009 1:41 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] Inline assembler and compiler optimization > > As Weddington, Eric wrote: > > > If we do that, we might as well make it a public symbol, yes?: > > #define memory_barrier() __asm__ __volatile__(""::"memory") > > I hesitate to add stuff like that to existing header files. > memory_barrier belongs into the application namespace, so existing > applications could legitimately already use that name (and are likely > doing it in case they really need the functionality). > > Would you like _MEMORY_BARRIER() more? That's in the implementation > namespace.
Let's see if something is available to us in the builtins. > Likewise, the same goes for using nop(), as tempting as it is. Again, > _NOP() would be fine, as will __nop(). Hmm. I think that might be included as part of the new builtins for the AVR port. > Another definition that just came to mind: setting the JTD bit, a > timed sequence. See here: > > http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopi > c&p=553919#553836 > > for a sample implementation. I wouldn't see any of the existing > header files where that really fits. (It needs to be polished up, I > think some controllers use MCUCR, and some use MCUCSR for JTD.) We definitely need to create an API for this, and all other timed sequences. There are a number of timed sequences in the xmega chips that need to be added. I know you don't care too much about xmega, because of inability to program it with avrdude. But a visual inspection of the resulting code from an inline assembly macro would be good enough for me. > If we decide for a new header file, how to name it? <avr/asm.h>? > <avr/misc.h>? I don't like misc as it is too vague. For the JTD timed sequence, why not a new <avr/jtag.h> file? It doesn't matter to me that it may only have one macro in it. At least it would be easy to remember. Eric _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
