Re: Howto I/O in asm instructions?]

View: New views
2 Messages — Rating Filter:   Alert me  

Re: Howto I/O in asm instructions?]

by Kevin-11 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

  Do we _really_ have to go through such pain just to write some in-line
assembly in gcc?  THAT could sure use some streamlining in the avr-gcc
compiler.  In-line assembly is pretty much a must for embedded work.
Rather than do that I'll write assembly functions and link them in, this
is just too ugly to contemplate!

IMO,
DLC

> Ruud Vlaming schreef:
>> Hi,
>>
>> There are a couple of ways to use i/o address in assymbly.
>> Below i used a some:
>>
>> #define _EEARL_ "0x1E"
>> uint8_t portFSReadByte(unsigned char * pAddress)
>> { uint8_t result;
>>   asm volatile ( \
>>    "in   r26, __SREG__      \n\t"
>>    "cli                     \n\t"
>>    "out  %2, %A0            \n\t"
>>    "out  "_EEARL_", %B0     \n\t"
>>    "sbi  __EECR__, 0        \n\t"
>>    "in   %A0, 0x1D          \n\t"
>>    "out __SREG__, r26       \n\t"
>>    "" :"=r" (result) :"0" (pAddress), "I" (_SFR_IO_ADDR(EEARH)) : "r26"
>> );
>>   return result; }
>>
>> (1) You can define a constant, like i did for _EEARL_
>>   This is nice but no so portable.
>> (2) You can use the asm paramter list, like for EEARH
>>   Also nice, but errorprone, since i keep making mistakes in
>>   numbering, especially when you have many parameters and
>>   have to change something.
>> (3) The best thing to have would be something like __EECR__,
>>   resembling the definition for __SREG__, but that does not
>>   compile right now.
>>
>> Is the latter possible somehow? Or are there other solutions?
>
> You could go for option 2 if you use syntax like this (took this from
> eeprom.h)
>
>      __asm__ __volatile__ (
>          "/* START EEPROM WRITE CRITICAL SECTION */\n\t"
>          "in r0, %[__sreg] \n\t"
>          "cli \n\t"
>          "sbi %[__eecr], %[__eemwe] \n\t"
>          "sbi %[__eecr], %[__eewe] \n\t"
>          "out %[__sreg], r0 \n\t"
>          "/* END EEPROM WRITE CRITICAL SECTION */"
>          :
>          : [__eecr]  "i" (_SFR_IO_ADDR(EECR)),
>            [__sreg]  "i" (_SFR_IO_ADDR(SREG)),
>            [__eemwe] "i" (EEMWE),
>            [__eewe]  "i" (EEWE)
>          : "r0"
>      );
>
> This makes the code far more readable IMHO. For more info on the %[ ]
> notation take look at:
> http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Extended-Asm.html
>
> HTH
>
> Wouter
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>


--
Dennis Clark
TTT Enterprises


--
Dennis Clark
TTT Enterprises



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: Howto I/O in asm instructions?]

by Joerg Wunsch :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dennis Clark <dlc@...> wrote:

>   Do we _really_ have to go through such pain just to write some
> in-line assembly in gcc?

What's your pain with it?

GCC's inline assembler is essentially tied deep into the compiler.
This allows for it to be /very/ flexible, and fully integrated into
the optimization framework of the compiler, as the developer can be
very explicit about specifying his needs.  The downside, of course, is
that a flexible method is usually not outright a simple one.

Contrast that with other compiler's inline asemblers where you
essentially have to know how the register allocator of the compiler is
going to work, so to guess which registers your operands might be in
when the inline assembler is executed -- and you could be completely
hosed with the next compiler version when someone tuned the register
allocator.

My personal opinion (and I know others are sharing this one) is that
GCC's inline assembler is nothing to be used by beginners, but merely
by either experienced users, and even more by library developers.

>  THAT could sure use some streamlining in the avr-gcc
> compiler.

What exactly are you talking about here?  Do you really /know/ GCC's
inline assembler and its options?

>  In-line assembly is pretty much a must for embedded work.

Care to explain?

If you've got some time-critical function which you would want to
write an optimized assembly implementation for: do so.  Don't use the
inline assembler, but use a separate assembly source file.  I don't
see any reason why using an inline assembly statement would gain
anything in that situation.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list