On Fri, 2002-02-01 at 22:26, Daniel Jacobowitz wrote: > On Fri, Feb 01, 2002 at 03:15:13PM -0800, H . J . Lu wrote: > > On Fri, Feb 01, 2002 at 06:01:26PM -0500, Daniel Jacobowitz wrote: > > > On Fri, Feb 01, 2002 at 10:29:43AM -0800, H . J . Lu wrote: > > > > On Fri, Feb 01, 2002 at 12:45:02PM +0100, Maciej W. Rozycki wrote: > > > > > On Thu, 31 Jan 2002, H . J . Lu wrote: > > > > > > > > > > > > Gas will fill delay slots. Same object codes will be produced, so I > > > > > > > think you don't have to do that by hand. > > > > > > > > > > > > It will make the code more readable. We don't have to guess what > > > > > > the assembler will do. > > > > > > > > > > But you lose a chance for something useful being reordered to the slot. > > > > > That might not necessarily be a "nop". Please don't forget of indents > > > > > anyway. > > > > > > > > > > > > > Here is a new patch. I use branch likely to get rid of nops. Please > > > > tell me which indents I may have missed. > > > > > > Can you really assume presence of the branch-likely instruction? I > > > don't think so. > > Actually, regardless of whether modern cpus implement it, I'd argue that avoiding the branch likely is a good idea for 2 reasons: 1) In the latest MIPS specs (mips32 and mips64) branch likelies have officially been deprecated as probable removals from the architecture in the not-too-distant future. 2) More importantly, most implementations don't use any sort of dynamic branch prediction on branch likelies. They predict taken, always, since that's the specified intent (it's a branch *likely* to be taken). For most spin locks, the normal behaviour is a fall through, not taking that branch, so you're inflicting a branch mispredict penalty on every lock grabbed without contention. Even for locks which the general case is contention, giving the processor branch predictor a chance to learn that is a Good Idea. -Justin
