Re: Compiler support for Intel-MMX?

>Michael Tiomkin wrote:
>> From 1996, Intel tried to persuade compiler vendors to start using
>> the "intrinsics" approach for MMX. The intrinsics are something
>> between the direct C support and inlined assembly: you have a set
>> of C "functions" that can be inlined into MMX (or other processor
>> extravaganza) instructions.


Olivier Lefevre <nnylfv@ny.ubs.com> writes:
>Am I correct that this is also the approach adopted by SUN in their
>VIS SDK or am I off the mark? Even if I am correct there is a big
>difference, namely that SUN's "VIS macros" are available to users
>whereas Intel's "intrinsics" seem to belong within the compiler,
>leaving users w/ nothing but assembly if they want to write MMX code
>by themselves (and a compiler that doesn't support intrinsics, that
>is). Again, is this correct?


The way the Sun Workshop compilers handle VIS instructions is mainly
through the use of "inline templates". These are small routines
written in assembly language using the ABI calling conventions and
intended to be used to replace the call instruction of the same name.
There is one inline template for each VIS instruction in the vis.il
file supplied with the VIS SDK. The user writes C code that is full
of calls to these special routines.


Using inline templates is a replacement for inline asm() with a more
well defined interface (i.e. a calling convention for register usage).
Also, inline templates are a more general extension mechanism than
intrinsic functions, as users can invent their own. However, inline
templates are not necessarily very portable to other compilers,
esp. the with any kind of performance.


Originally, these inline templates were copied into the assembly
language before final assembly. Now, the optimizing code generator
reads these templates, virtualizes the registers, and feeds them into
the code stream so they can get optimized along with the rest of the
code. This includes doing software pipelining in some cases, as well
as register allocation and instruction scheduling.


We have considered using VIS directly from the compiler itself, as
vectorization is easy once you can do parallelization, but there are
two factors that can make using these types of special multimedia
instructions (VIS/MMX/etc.) difficult.


1. The datatypes are sometimes slightly different the C data types,
      e.g. fixed-point datatypes.


2. The set of operations is not necessarily very complete (or regular),
      e.g. for 32-bit integers, there is no direct way to multiply or divide.


Both of these factors increase the complications in generating code,
and potentially decrease the number of cases where use of the special
instructions is worthwhile (i.e. faster).


Hope this clarifies things a bit,
Peter.
----------------------------
Peter C. Damron, (not speaking for) Sun Microsystems, Inc.
Workshop Compilers, UMPK 16-303, 901 San Antonio Road, Palo Alto, CA 94303
peter.damron@eng.sun.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.