[U-Boot] lib_arm global data pointer
Drasko DRASKOVIC
drasko.draskovic at gmail.com
Tue Jul 14 15:22:05 CEST 2009
Dear Wolfgang Denk.
>On Mon, Jul 13, 2009 at 9:34 PM, Wolfgang Denk <wd at 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.html
(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=64978&postdays=0&postorder=asc
And this:
http://www.nabble.com/bug-or-feature--CSE-optimizes-away-global,-fixed-register-td23909408.html
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
More information about the U-Boot
mailing list