Re: MS/CW-style inline assembly for GCC

[Richard Earnshaw <Richard dot Earnshaw at arm dot com>]

On Sat, 2004-05-08 at 21:43, Geoff Keating wrote:
> "Richard Earnshaw" <Richard.Earnshaw@arm.com> writes:
> 
> > On Fri, 2004-05-07 at 22:38, Paul Koning wrote:
> > 
> > > I think an asm statement with any semantics OTHER than "make this
> > > block of instructions appear in the binary exactly as written" is
> > > badly broken.  (Yes, that's why the MIPS assembler is bogus --
> > > although there at least you can tell it ".set noreorder".)
> > > 
> > 
> > I used to think that way myself, but these days I'm not so sure.  Modern
> > processors perform abysmally if code is not correctly scheduled, and
> > there's no way that a programmer can tune their code for every variant
> > of a CPU on the market.  Allowing the tools to reschedule the contents
> > of ASM blocks is potentially a major win.
> > 
> > It's true that there are cases where the ordering is subtly important,
> > but as you say, there are ways to avoid scheduling in those cases.
> > 
> > It's always dangerous to say "never"!
> 
> Why wouldn't you write the code in C in these cases?  It seems to me
> that if you're willing to have the compiler schedule the code, you
> might as well let it select the instructions and do register
> allocation as well.

All sorts of reasons.  Maybe C has no way to express the problem
efficiently (eg arbitrary-precision arithmetic).

But it's not necessarily restricted to code going through the compiler. 
There are aspects of operating systems (interrupt entry layers) that
pretty much have to be written in assembler (because they are
manipulating modes, etc), but where tuning for a particular CPU could
make quite a difference to the interrupt latency on the machine.

I'm not saying it should always be done, just that there are times when
it might be advantageous.  The only key point is that there isn't a
hard-and-fast rule that can be applied in all circumstances.

R.