[U-Boot-Users] relocate_code
<u-boot>/cpu/mpc8xx/start.S
.... .... .globl relocate_code relocate_code: mr r1, r3 /* Set new stack pointer */ mr r9, r4 /* Save copy of Global Data pointer */ mr r10, r5 /* Save copy of Destination Address */ .... cmplw cr1,r3,r4 addi r0,r5,3 srwi. r0,r0,2 beq cr1,4f /* In place copy is not necessary */ beq 7f /* Protect against 0 count */ mtctr r0 bge cr1,2f ^^^^^^^^^^ why we need to differeciate the two situation, addr>CFG_MONITOR_BASE and addr<=CFG_MONITOR_BASE
la r8,-4(r4) la r7,-4(r3) 1: lwzu r0,4(r8) stwu r0,4(r7) bdnz 1b b 4f
2: slwi r0,r0,2 <<----------------- i think above code will be enough for the two add r8,r4,r0 situation add r7,r3,r0 3: lwzu r0,-4(r8) stwu r0,-4(r7) bdnz 3b .... ....
thnx best regards
On Sat, 04 Jan 2003 00:22:21 +0800, YanMin Qiao sepherosa@sohu.com writes: ...
cmplw cr1,r3,r4
...
bge cr1,2f
...
1: lwzu r0,4(r8) stwu r0,4(r7) bdnz 1b b 4f
2: slwi r0,r0,2 <<----------------- i think above code will be enough for the two add r8,r4,r0 situation add r7,r3,r0 3: lwzu r0,-4(r8) stwu r0,-4(r7) bdnz 3b
One is copying forwards, the other is copying backwards - you can see the lwzu/stwu pair of instructions either add +4 or -4 to the registers containing the source and destination addresses (the "u" means to update the index register with the resulting memory address).
Be careful with the first "bge" above - it isn't testing the result of the previous instruction, it is testing the result of the "cmplw" done quite a few instructions beforehand and stored in "cr1" i.e. it will branch if "r3" (the destination address) is >= "r4" (the source address) i.e. if it is possible that the copy will overwrite the source.
The Powerpc CPU has four(?) condition code sets where results of operations can be stored. While I don't understand the details, I presume it has something to do with the instruction pipeline and avoiding unnecessary flushes - esp. when you consider that the programmer can indicate whether a branch is likely or not with a bit in the instruction - I presume (again) that this determines whether the processor does pre-fetching or something like that. Details of all this stuff is in the Powerpc Programmer's Environment Manual (I think).
If you look through the latest linux kernel source you often see things like
if (unlikely(<condition>)) {
or
if (likely(<condition>)) {
On powerpc (I'm guessing) these macros will set an attribute for the compiler which will result in this bit being set or cleared in the branch instruction of the resulting assembly code - I guess it does something similar for later Pentium processors (and nothing at all if the processor doesn't have these sort of features). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
Murray Jensen wrote:
On Sat, 04 Jan 2003 00:22:21 +0800, YanMin Qiao sepherosa@sohu.com writes: ...
cmplw cr1,r3,r4
...
bge cr1,2f
...
1: lwzu r0,4(r8) stwu r0,4(r7) bdnz 1b b 4f
2: slwi r0,r0,2 <<----------------- i think above code will be enough for the two add r8,r4,r0 situation add r7,r3,r0 3: lwzu r0,-4(r8) stwu r0,-4(r7) bdnz 3b
One is copying forwards, the other is copying backwards - you can see the lwzu/stwu pair of instructions either add +4 or -4 to the registers containing the source and destination addresses (the "u" means to update the index register with the resulting memory address).
First thanks for your answer, howerever, my question is Why we copy _forward_ when _memory address_ <CFG_MONITOR_BASE, but when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? Is it because some overlapping problem when copy?
Be careful with the first "bge" above - it isn't testing the result of the previous instruction, it is testing the result of the "cmplw" done quite a few instructions beforehand and stored in "cr1" i.e. it will branch if "r3" (the destination address) is >= "r4" (the source address) i.e. if it is possible that the copy will overwrite the source.
thanks, I know
The Powerpc CPU has four(?) condition code sets where results of operations can be stored. While I don't understand the details, I presume it has something to do with the instruction pipeline and avoiding unnecessary flushes - esp. when you consider that the programmer can indicate whether a branch is likely or not with a bit in the instruction - I presume (again) that this determines whether the processor does pre-fetching or something like that. Details of all this stuff is in the Powerpc Programmer's Environment Manual (I think).
If you look through the latest linux kernel source you often see things like
if (unlikely(<condition>)) {
or
if (likely(<condition>)) {
On powerpc (I'm guessing) these macros will set an attribute for the compiler which will result in this bit being set or cleared in the branch instruction of the resulting assembly code - I guess it does something similar for later Pentium processors (and nothing at all if the processor doesn't have these sort of features). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
In message 3E164AC7.1050505@sohu.com you wrote:
Why we copy _forward_ when _memory address_ <CFG_MONITOR_BASE, butwhen _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? Is it because some overlapping problem when copy?
Right (although not very likely here).
(the destination address) is >= "r4" (the source address) i.e. if it is possible that the copy will overwrite the source.
thanks, I know
Ummmm... Why do you ask when you already know?
Best regards,
Wolfgang Denk
On Sat, 04 Jan 2003 10:45:27 +0800, YanMin Qiao sepherosa@sohu.com writes:
First thanks for your answer, howerever, my question is Why we copy _forward_ when _memory address_ <CFG_MONITOR_BASE, but when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? Is it because some overlapping problem when copy?
Yes. It is generic memory copying code - if it is at all possible that the copy might overwrite the destination then it goes backwards, instead of forwards. It shouldn't make a lot of difference either way (I guess I can imagine a scenario where it stuffs up some fancy pre-fetching in the CPU, which might make it go half or a third of the speed, but its not likely).
Be careful with the first "bge" above - it isn't testing the result of the previous instruction, it is testing the result of the "cmplw" done quite a few instructions beforehand and stored in "cr1" i.e. it will branch if "r3" (the destination address) is >= "r4" (the source address) i.e. if it is possible that the copy will overwrite the source.
thanks, I know
OK, I was just trying to be thorough. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
Thank you for your detail answer :) , I see them now.
Best regards
Murray Jensen wrote:
On Sat, 04 Jan 2003 10:45:27 +0800, YanMin Qiao sepherosa@sohu.com writes:
First thanks for your answer, howerever, my question is Why we copy _forward_ when _memory address_ <CFG_MONITOR_BASE, but when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? Is it because some overlapping problem when copy?
Yes. It is generic memory copying code - if it is at all possible that the copy might overwrite the destination then it goes backwards, instead of forwards. It shouldn't make a lot of difference either way (I guess I can imagine a scenario where it stuffs up some fancy pre-fetching in the CPU, which might make it go half or a third of the speed, but its not likely).
Be careful with the first "bge" above - it isn't testing the result of the previous instruction, it is testing the result of the "cmplw" done quite a few instructions beforehand and stored in "cr1" i.e. it will branch if "r3" (the destination address) is >= "r4" (the source address) i.e. if it is possible that the copy will overwrite the source.
thanks, I know
OK, I was just trying to be thorough. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen@csiro.au
Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/
To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.
The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.
participants (3)
-
Murray Jensen -
Wolfgang Denk -
YanMin Qiao