All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.