Re: [avr-gcc-list] Accessing C sram locations in inline asm

[Theodore A. Roth]

My guess is that the assembler doesn't know what sram_byte is. You should be 
using constraints in your asm statements (the "::" part). If you don't know 
how to do this, you might want to read this:

http://freesoftware.fsf.org/download/avr-libc/doc/avr-libc-user-manual/inline_asm.html

Ted Roth


On Thu, 5 Sep 2002, Grant Stockly wrote:

:)My main.c file includes this (before the main function):
:)
:)unsigned char sram_byte;
:)unsigned char sram_byte2;
:)
:)and inside the main function:
:)   sram_byte++;;
:)   sram_byte2++;
:)   asm volatile("lds __tmp_reg__, sram_byte" :: );
:)   asm volatile("lds __tmp_reg__, sram_byte2" :: );
:)
:)I've also tried "sram_byte-0x800060" in the place of the above, same results.
:)
:)This -should- produce some interesting stuff in the list file.   When I 
:)examine the list file I'm not getting the results I'd expect.  It seems 
:)that no matter what I try, the address of both sram_byte and sram_byte2 is 
:)coming out at 0x0000 even though I can see the correct address in main.map
:)
:)  154 0016 8091 0000             lds r24,sram_byte
:)  155 001a 8F5F                  subi r24,lo8(-(1))
:)  156 001c 8093 0000             sts sram_byte,r24
:)   35:main.c        ****   sram_byte2++;
:)  157                            .stabn 68,0,35,.LM4-main
:)  158                    .LM4:
:)  159 0020 8091 0000             lds r24,sram_byte2
:)  160 0024 8F5F                  subi r24,lo8(-(1))
:)  161 0026 8093 0000             sts sram_byte2,r24
:)
:)
:)  149 0008 0090 0000             lds __tmp_reg__, sram_byte
:)   31:main.c        ****
:)   32:main.c        ****   asm volatile("lds __tmp_reg__, sram_byte2" :: );
:)  150                            .stabn 68,0,32,.LM3-main
:)  151                    .LM3:
:)  152 000c 0090 0000             lds __tmp_reg__, sram_byte2
:)
:)
:)Why in the world does none of the compiler generated code contain 
:)addresses!  The address in sram to be loaded is supposed to be the second 
:)16bits of the operand, right?  Store is the first 16.  Can anyone tell me 
:)the mistakes I'm making here?  Everything I've shown compiles without 
:)error.  Does the assembler take the main.map and apply it something else to 
:)replace all of those 0x0000s?
:)
:)Thanks for your time,
:)Grant
:)
:)avr-gcc-list at http://avr1.org
:)

avr-gcc-list at http://avr1.org