From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 30 Nov 2010 10:25:21 +0100 Subject: [U-Boot] [PATCH RFC 1/3] arm920t: do not set register useless In-Reply-To: <4CF4B5BC.1090500@gmail.com> References: <1291100800-61850-1-git-send-email-andreas.devel@googlemail.com> <1291100800-61850-2-git-send-email-andreas.devel@googlemail.com> <4CF4B0A9.6030209@aribaud.net> <4CF4B5BC.1090500@gmail.com> Message-ID: <4CF4C301.3090709@aribaud.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 30/11/2010 09:28, Andreas Bie?mann a ?crit : >>> + beq clear_bss /* skip relocation */ >>> + mov r1, r6 >> >> Why use r1? > > Use a scratch register here cause stmia Rn! does increment Rn. > Therefore usage of r6 here would destroy the saved 'addr of > destination'. Cause that fact we have saved the 'addr of destination' @ > beginning of relocate_code twice, once to r6 and once to r7. This is > obviously not needed iv we change the register in copy_loop (which was > already used in comment .. if you saw that on the end of the line). Understood. > I doubt if this a 'speed up' but we can have a cleaner interface. We > have r4, r5, r6 as storage of input values to relocate_code. We do only > use scratch registers for copy_loop, fixloop for relocation, clear_bss > later on. We do decide if we need fixloop for relocation or if we can > skip that and then setup the relevant scratch registers. > > Well this is only an RFC. I found that plus the NULL pointer stuff worth > to mention. It is not that important to get this special patch in cause > the current implementation do also work. The r8 issue and the zero-filled reloc entry issue are important to pull in as they can cause all sorts of time-wasting issues. > regards > > Andreas Bie?mann Amicalement, -- Albert.