Inline assembly syntax

[Ian Lance Taylor]

"Timothy J. Wood" <tjw@omnigroup.com> writes:

> > So, putting these together, the ideal assembler syntax would have
> > characteristics like these:
> 
>    What about having a really good set of intrinsic functions.  For
> example, Apple ships with a header called ppc_intrinsics.h that has
> single-instruction inline functions for all the common instructions
> (with presumably correct constraints).

I think intrinsics are a good idea.  In fact, we could generate many
intrinsics directly from the machine description if we wanted to.
Another big advantage of intrinsics which you didn't specifically call
out is that the compiler has enough information to schedule them
properly.

There are still reasons to use some sort of inline assembler, though:

* Operations which use a carry flag or other aspects of a processor
  status word.  These are generally not described in RTL at present,
  and are generally rather difficult to describe.  We need to describe
  them to support intrinsics correctly, as otherwise gcc will not
  understand the dependencies between instructions.

* Supervisor calls.  The effects of a call into the operating system
  are inherently system dependent, and thus can not generally be
  described by compiler intrinsics.  We can't require everybody who
  rolls their own RTOS to modify the compiler.

* load/locked store/conditional operations are difficult to model
  using intrinsics.  I guess you would wind up using scheduling
  barriers around each instruction, which would be awkward.

* Things like MIPS coprocessor 0 instructions vary widely between
  particular MIPS implementations, which are otherwise more or less
  identical from the compiler's point of view.  It would be tedious
  and somewhat error prone to try to capture all the scheduling
  requirements of these instructions for each processor variant.

* One use of inline assembler is to use new instructions which gcc
  does not yet know about.  Any set of intrinsics functions is
  inevitably going to lag behind processor releases, particularly for
  people who work with official gcc releases.

Ian