hello, On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer <amd...@gmail.com> wrote: > On Dec 1, 2010 12:26 AM, "奥刘" <happyo...@gmail.com> wrote: > >> In the file .\cpu\mips\cache.s , i found some code confounded . >> >> line 152 to line 156 : >> >> cache_op Index_Store_Tag_I t0 >> PTR_ADDU t0, a2 >> bne t0, t1, 1b >> /* fill once, so data field parity is correct */ >> PTR_LI t0, INDEX_BASE >> >> the code 'PTR_LI t0, INDEX_BASE' is in the branch delay slot , so this >> instruction will be implement every branch cycle. >> >> Is it right ? Then the cache operation logic seems wrong .
It would seem. a NOP is needed in this case. seem every branch is incorrect. a disassembly would be best way to confirm. assembler might insert it for us. > > From a quick glance I think the code is OK. I would suggest > disassembling the executable code to make sure of what the assembler > did. > > The answer depends on what mode the assembler is in. For MIPS > assembler there is a 'reorder mode' where the assembler will fill in > the branch delay slot for you or place a nop if necessary, and the > next instruction in the source is really the one after the delay slot, > or there is noreorder mode where the next instruction after the branch > is what is put in the delay slot. > > Normally the assembler runs in reorder mode, and you use a '.set > reorder' and '.set noreorder' to switch between them. Noreorder mode > is commonly used in code that requires precise control of where > instructions get executed (cache & tlb handling) the file does specify noreorder! This is interesting, and of course I will be looking at a disassembly of my u-boot later, it is not available to me now. Tho, the cache's work, and have seen nothing that makes it seem otherwise.. -- Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot