Re: Delay slots

[Warner Losh <wlosh%bsdimp.com@localhost>]

> On Jun 21, 2016, at 12:31 PM, coypu%SDF.ORG@localhost wrote:
> 
> On Mon, Jun 20, 2016 at 06:04:39PM +0000, Paul_Koning%Dell.com@localhost wrote:
>> As for "gas" and reordering, I have always viewed assembler reordering as a very large design error.  Assemblers should assemble; if I meant something different from what I wrote I would have written the other thing instead.  Reordering by programs belongs in compilers, not assemblers.  Note that GCC for years now has used gas in no-reorder mode for this exact reason -- gas does a horrible job, gcc knows far more about what should be done.
>> 
> I see your point now, it seems whoever wrote much of the MIPS code in
> NetBSD felt the same - there's set noreorder almost everywhere.

A big reason is that many bits that are in assembler are somewhat constrained
in how big they can be or what they can do. You’ll see lots of .set noat as well
since there are places you simply can’t trash the ‘at’ register when executing
in trap handler, but addresses need to be loaded so gas has special case code
to ensure that they are loaded properly (eg by only touching k0 and k1).

As much as this feature of gas is bad mouthed, for many years it was actively
helpful and produced better code. It has only been more recently that compilers
optimizers have grown enough to track delay slots so it can pick the absolute best
thing for the delay slot, rather than the old algorithm of ‘any work saved is good’ which
is a great ‘peephole’ optimization, but as others have noted has its limitations or gets
in the way of more global register flow analysis.

Warner