On Fri, 13 Jul 2001, Ralf Baechle wrote: > > Hmm, I would consider that a bug in such an assembler. The mtc0 and > > possibly the mfc0 opcode should be treated as reordering barriers as they > > may involve side effects an assembler might not be aware of. > > Assembler is the art of using sideeffects so things are fairly explicit. > Optimizations are controlled using > > .set noreorder / reorder > .set volatile / novolatile > .set nomove / nomove > .set nobopt / bopt Sure, but sometimes ".set reorder" allows you to achieve better optimization across various ISAs without a need to resort to the preprocessor. Consider the following code: lw $1,($2) addu $3,$1 You need an instruction between the two for a MIPS I CPU but MIPS II+ CPUs interlock here if no instruction is placed. Assuming no real instruction can be reordered here, a nop must be inserted if the code gets compiled for a MIPS I CPU but no instruction is preferred otherwise. The assembler does it automatically if the ".set reorder" directive is active, but you need to decide yourself if it is not. Actually with mfc0 there is no problem -- you need a nop in the case like the above one as coprocessor transfers never interlock; at least docs state so. But who believes docs without a grain of salt, so please correct me if I am wrong (I don't have appropriate hardware to perform a test). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
