Re: Delay slots
Warner Losh <[email protected]> Tue, 21 Jun 2016 12:37:50 -0600
| Newsgroups | gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.ports.pmax |
|---|---|
| Message-ID | <[email protected]> |
> On Jun 21, 2016, at 12:31 PM, [email protected] wrote: > > On Mon, Jun 20, 2016 at 06:04:39PM +0000, [email protected] 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