Dear Albert,
Am Mi 21 Sep 2011 16:23:56 CEST schrieb Albert ARIBAUD:
Le 21/09/2011 14:31, Andreas Bießmann a écrit :
Dear Albert,
Am Mi 21 Sep 2011 14:03:09 CEST schrieb Albert ARIBAUD:
Le 21/09/2011 13:20, Andreas Bießmann a écrit :
Dear "GROYER, Anthony", Dear Albert,
Am Mi 21 Sep 2011 12:51:33 CEST schrieb Albert ARIBAUD:
Le 21/09/2011 11:29, GROYER, Anthony a écrit :
<snip>
Apart from your question (how are the number of registers in ldmia and stmia speed related to the speed of the copy loop?) there is another one: how do we handle the fact that the length to copy may not be a multiple of the ldmia/stmia 'width'? Even in arm926ejs/start.S, two registers are used, but the alignment for text+data is 4 bytes, not 8.
Good point. Well, we could implement some 'rewind' apart from .bss zeroing, if we care about it. I guess this could be done without any impact to copy time, if we really save time by using more regs for ldmia/stmia.
But how about reading beyond the _end symbol from flash crossing some border e.g. end of address space, end of flash space ... ?
This did not bite us so far, and should not, since we're going to copy into the space after .text, which *should* be .bss, which we'll zero right after. But Murphy's law could hit...
As for r8, it should be preserved as it points to gd, but that is ensured by the C code already IIRC.
We use -ffixed-r8 therefore the compiler takes care for the C part, but we need to respect this in asm.
in arm926ejs/start.S we do. If there are other start.S files where r8 is trashed, they should be fixed indeed.
There should no one else left, my last changeset fixed it globally: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/90010/focus=90013
best regards
Andreas Bießmann