Programming-Guides/Porting_Vector_Intrinsics/sec_handling_mmx.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Copyright (c) 2017 OpenPOWER Foundation
  
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
  
-->
<section xmlns="http://docbook.org/ns/docbook"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  version="5.0"
  xml:id="sec_handling_mmx">
  <title>Dealing with MMX</title>
  
  <para>MMX is actually the harder case. The <literal>__m64</literal>
  type supports SIMD vector 
  int types (char, short, int, long).  The  Intel API defines  
  <literal>__m64</literal> as:
  <programlisting><![CDATA[typedef int __m64 __attribute__ ((__vector_size__ (8), __may_alias__));]]></programlisting></para>

  <para>Which is problematic for the PowerPC target (not really supported in 
  GCC) and we would prefer to use a native PowerISA type that can be passed in a 
  single register.  The PowerISA Rotate Under Mask instructions can easily 
  extract and insert integer fields of a General Purpose Register (GPR). This 
  implies that MMX integer types can be handled as an internal union of arrays for 
  the supported element types. So a 64-bit unsigned long long is the best type 
  for parameter passing and return values, especially for the 64-bit (_si64) 
  operations as these normally generate a single PowerISA instruction.
  So for the PowerPC implementation we will define
  <literal>__m64</literal> as:
  <programlisting><![CDATA[typedef __attribute__ ((__aligned__ (8))) unsigned long long __m64;]]></programlisting></para>

  <para>The SSE extensions include some copy / convert operations for 
  <literal>_m128</literal> to / 
  from <literal>_m64</literal> and this includes some int to / from float conversions. However in 
  these cases the float operands always reside in SSE (XMM) registers (which 
  match the PowerISA vector registers) and the MMX registers only contain integer 
  values. POWER8 (PowerISA-2.07) has direct move instructions between GPRs and 
  VSRs. So these transfers are normally a single instruction and any conversions 
  can be handled in the vector unit.</para>

  <para>When transferring a <literal>__m64</literal> value to a vector register we should also 
  execute a xxsplatd instruction to insure there is valid data in all four 
  float element lanes before doing floating point operations. This avoids causing 
  extraneous floating point exceptions that might be generated by uninitialized 
  parts of the vector. The top two lanes will have the floating point results 
  that are in position for direct transfer to a GPR or stored via Store Float 
  Double (stfd). These operation are internal to the intrinsic implementation and 
  there is no requirement to keep temporary vectors in correct Little Endian 
  form.</para>

  <para>Also for the smaller element sizes and higher element counts (MMX 
  <literal>_pi8</literal> and <literal>_p16</literal> types)
  the number of  Rotate Under Mask instructions required to 
  disassemble the 64-bit <literal>__m64</literal> 
  into elements, perform the element calculations, 
  and reassemble the elements in a single <literal>__m64</literal> 
  value can get larger. In this 
  case we can generate shorter instruction sequences by transfering (via direct 
  move instruction) the GPR <literal>__m64</literal> value to the 
  a vector register, performance the 
  SIMD operation there, then transfer the <literal>__m64</literal> 
  result back to a GPR.</para>
  
</section>