On Mon, 4 Feb 2002, Ralf Baechle wrote: > > It will make the code more readable. We don't have to guess what > > the assembler will do. > > Generally speaking a MIPS assembler is free to do arbitrary reordering. > In the past there have been non-GNU assembler that were doing more massive > reordering than gcc does ... Using .set noreorder means you dump the > assembler's intelligence and take full responsibility for dealing with > all interlocks (or the lack thereof) and other performance issues > yourself. That's why I'm still uneasy about the patch or, specifically, its _test_and_set hunk. It's best to avoid pretending we have the knowledge beyond what an assembler has, as it's often not the case -- consider all the options an assembler can accept for code variations. Using "noreorder" is really justified if you need to generate an exact opcode stream for some reason (perhaps for a trampoline with a fixed format) or you know you have the knowledege beyond what an assembler has, e.g. you know an instruction can (or must) really be placed in a delay slot even though a dependency analysis performed by an assembler shows otherwise. Also beware of implicit macros which may expand into multiple instructions -- their semantics when placed in a delay slot may differ from what one may expect! -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
