On Wed, 16 Apr 2003, Hartvig Ekner wrote: > Which is: > > 80109654 <r4k_clear_page_d32>: > 80109654: 24811000 addiu $at,$a0,4096 > 80109658: bc8d0000 cache 0xd,0($a0) > 8010965c: fc800000 sdc3 $0,0($a0) > 80109660: fc800008 sdc3 $0,8($a0) > 80109664: fc800010 sdc3 $0,16($a0) > 80109668: fc800018 sdc3 $0,24($a0) > 8010966c: 24840040 addiu $a0,$a0,64 > 80109670: bc8dffe0 cache 0xd,-32($a0) > 80109674: fc80ffe0 sdc3 $0,-32($a0) > 80109678: fc80ffe8 sdc3 $0,-24($a0) > 8010967c: fc80fff0 sdc3 $0,-16($a0) > 80109680: 1424fff5 bne $at,$a0,80109658 <r4k_clear_page_d32+0x4> > 80109684: fc80fff8 sdc3 $0,-8($a0) > 80109688: 03e00008 jr $ra > > It seems much of the r4k cache code assumes the presence of SD - which breaks on all MIPS32 CPU's? Not much -- only arch/mips/mm/pg-r4k.S. It looks like MIPS32 needs an own implementation -- trivially different and half as fast. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
