public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: YanMin Qiao <sepherosa@sohu.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] relocate_code
Date: Sat, 04 Jan 2003 21:28:15 +0800	[thread overview]
Message-ID: <3E16E16F.6020601@sohu.com> (raw)
In-Reply-To: 21605.1041684608@msa.cmst.csiro.au

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 at 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.
>
>
>  
>

  reply	other threads:[~2003-01-04 13:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 16:22 [U-Boot-Users] relocate_code YanMin Qiao
2003-01-04  2:22 ` Murray Jensen
2003-01-04  2:45   ` YanMin Qiao
2003-01-04  8:08     ` Wolfgang Denk
2003-01-04 12:50     ` Murray Jensen
2003-01-04 13:28       ` YanMin Qiao [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-06 15:18 [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Wolfgang Denk
2003-01-20 20:12 ` [U-Boot-Users] relocate code Jerry Walden
2003-01-20 21:23   ` Wolfgang Denk
2004-10-04  6:26 [U-Boot-Users] Relocate code raju rediff
2004-10-04  6:52 Holger L. Bille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E16E16F.6020601@sohu.com \
    --to=sepherosa@sohu.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox