Hi Thanks for the SP, I missed that. And apparently Atmel Studio also cannot find it, and underlines it with red error marker. It does compile, and I have found it in avr/common.h, it's probably a problem with __AVR_ARCH__ handling by AS... I guess that's what I get for trusting the IDE:)
I know that just reading SP is not enough, I do also use stack watermarking. It's just an additional diagnostic information. Note: SP can also be used to re-mark the unused stack to trace stack usage over time... (or mark stack on platforms without .init* sections.) Note #999: "the problem is in your code." This isn't actually my code. My code was written for ARM and looked something like this: unsigned int GetStackPointer() { volatile register unsigned int sp asm("r13"); return sp; } that someone ported to AVR, and now I'm fixing it... ;) Üdvözlettel, Szikra Istvan On Wed, Nov 8, 2017 at 7:10 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > Szikra Istvan schrieb: > >> Hi all, >> >> I have this interesting test case for you guys, and girls. >> >> #include <avr/io.h> >> >> unsigned int GetStackPointer() >> { >> volatile unsigned int sp = (SPH << 8) | SPL; >> > > There is "SP" for you. Ne need to hamper with bytes. > > uint16_t GetStackPointer (void) > { > return SP; > > } > > return sp; >> } >> >> int main(void) >> { >> while(1) >> { >> PORTA.OUT = GetStackPointer(); >> } >> } >> >> After building it with Atmel Studio 6.2 (default project settings, >> -mmcu=atxmega128a4u), AVR8/GNU C Compiler/Linker : 4.8.1 the .lss contains >> this gem: >> >> unsigned int GetStackPointer() >> { >> 21a: cf 93 push r28 >> 21c: df 93 push r29 >> 21e: 1f 92 push r1 >> 220: 1f 92 push r1 >> 222: cd b7 in r28, 0x3d ; 61 >> 224: de b7 in r29, 0x3e ; 62 >> volatile unsigned int sp = (SPH << 8) | SPL; >> 226: 2e b7 in r18, 0x3e ; 62 >> 228: 8d b7 in r24, 0x3d ; 61 >> 22a: 90 e0 ldi r25, 0x00 ; 0 >> 22c: 92 2b or r25, r18 >> 22e: 89 83 std Y+1, r24 ; 0x01 >> 230: 9a 83 std Y+2, r25 ; 0x02 >> return sp; >> 232: 89 81 ldd r24, Y+1 ; 0x01 >> 234: 9a 81 ldd r25, Y+2 ; 0x02 >> } >> 236: 0f 90 pop r0 >> 238: 0f 90 pop r0 >> 23a: df 91 pop r29 >> 23c: cf 91 pop r28 >> 23e: 08 95 ret >> >> (Atmel Studio 7 (Version: 7.0.1417), gcc version 5.4.0 >> (AVR_8_bit_GNU_Toolchain_3.6.0_1734) does the same.) >> (If anyone interested I can attach the whole compressed project.) >> > > A working test case is always preferred over binary clump :-) > > I'm mostly interested in the push r1, pop r0 pairs. >> Why? What are they doing? Who puts them there? Can someone "fix" the >> compiler/binutils? >> > > You used volatile which forces "sp" into the frame of the function. > As avr-gcc has to set up a frame pointer, this needs to push 2 more > bytes. Y is frame pointer and callee-saved here, this explains total > of 4 bytes of stack usage (not counting return address). > > This seems to be a bug for me. >> > > Not to me. > > Can someone "fix" the compiler/binutils? >> > > The only bug is in your code: > > o Forcing sp onto stack by volatile. > > o Using -O1 does not set -fomit-frame-pointer, hence even > without the volatile you get a frame pointer. To get > rid of it, use code that doesn't trigger a frame and > compile with optimization higher than -O1 and / or with > -fomit-frame-pointer. > > o Trying to get free stack by reading SP is a broken design. > For example, an ISR might consume way more space, which > will not be detected by your code. Consider code like > in "mem-check.c" from here: > > http://rn-wissen.de/wiki/index.php?title=Speicherverbrauch_ > bestimmen_mit_avr-gcc#Dynamischer_RAM-Verbrauch > > AFAIK r1 is the zero reg, and r0 is temp reg, so this should not cause >> problems, so it's not a critical bug, only optimization issue. >> (Unnecessary __tmp_reg__ =__zero_reg__ ) >> > > As already mentioned, the problem is in your code. > > And my optimal solution is >> unsigned int GetStackPointer() >> { >> union { unsigned int w; unsigned char b[2];} w; >> w.b[0] = SPL; w.b[1] = SPH; >> 21a: 8d b7 in r24, 0x3d ; 61 >> 21c: 9e b7 in r25, 0x3e ; 62 >> return w.w; >> } >> 21e: 08 95 ret >> > > No need for type punning unions, just use "SP" as explained above. > > Johann > >
_______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list