Dear Wolfgang Denk.
On Mon, Jul 13, 2009 at 9:34 PM, Wolfgang Denk wd@denx.de wrote: When I wrote "GCC's register usage conventions" I usually mean exactly that and not some completely different thing.
You also might want to read the README. Search for "On ARM, the following registers are used"...
On a first glance README actually tells that U-Boot will respect ATCPS (whith exception of r8, which it will reserve). So, actually, it can be that we were talking about the same thing, just that I used term ATPCS to underline that it is ARM (and not U-Boot or GCC) specific. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0042c/index.h... (http://www.nabble.com/Register-Usage-td23279910.html)
In any case, my code is working fine with r10 choice, which comes from the reasons I elaborated before (although maybe r10 would not be the happiest choice, but some of the regs r4-r9, r8 excluded).
This has nothing to do with ISRs at all. What makes you think so?
This, for example: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=64... And this: http://www.nabble.com/bug-or-feature--CSE-optimizes-away-global,-fixed-regis...
This gave me a hint that people using "volatile register" vars mostly in these cases. And I was thinking myself: why claiming our local reg as volatile? Who can change it appart from us, if not some other thread (written in assembly most probably, because if it was a C call then GCC would introduce prologue and epilogue to preserve register that are guaranteed to be non clobbered by ATCPS). So what other thread do we have in non-multithreaded U-Boot? So, I grepped to see who the hell is touching r8, and all I could find was (in cpu/armXXX/start.S) : .macro irq_save_user_regs sub sp, sp, #S_FRAME_SIZE stmia sp, {r0 - r12} @ Calling r0-r12 @ !!!! R8 NEEDS to be saved !!!! a reserved stack spot would be good. add r8, sp, #S_PC stmdb r8, {sp, lr}^ @ Calling SP, LR str lr, [r8, #0] @ Save calling PC mrs r6, spsr str r6, [r8, #4] @ Save CPSR str r0, [r8, #8] @ Save OLD_R0 mov r0, sp .endm chunk of code in ISR.
So, my suspicions comes from there.
The GCC mailing list is where GCC experts can answer your questions. I'm not a GCC expert - just a happy user since version 1.35 or so...
Thanks, I will investigate this interesting topic further and post on this thread if I come with reasonable solution. As I mentioned, my gcc was not working as I expected with "register volatile", as it was doing some optimization exibitions rather than plain register read/mov.
Some questions are also worth mentioning:
/* Pointer is writable since we allocated a register for it */ gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
Would not it be writable even if we did not allocated reg for it? We could have declared it as a global var without asm("r8") stuff and compiler would have put it on the stack - but I guess it would be writable.
And then: /* compiler optimization barrier needed for GCC >= 3.4 */ __asm__ __volatile__("": : :"memory");
Why is order of ams instructions important here? (I did not had time yet to recompile without this membar before posting this question, so I will try to do it and reproduce the problem).
Best regards, Drasko DRASKOVIC