hello,

On Wed, Dec 1, 2010 at 10:27 AM, Andrew Dyer amdyer@gmail.com wrote:

On Dec 1, 2010 12:26 AM, "奥刘" happyoach@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