Intel® OpenSource HD Graphics Programmer’s Reference Manual (PRM) Volume 4 Part 3: Execution Unit ISA (Ivy Bridge) For the 2012 Intel® Core™ Processor Family May 2012 Revision 1.0 NOTICE: This document contains information on products in the design phase of development, and Intel reserves the right to add or remove product features at any time, with or without changes to this open source documentation. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 Creative Commons License You are free to Share — to copy, distribute, display, and perform the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). No Derivative Works. You may not alter, transform, or build upon this work. ® INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Implementations of the I2C bus/protocol may require licenses from various entities, including Philips Electronics N.V. and North American Philips Corporation. Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Copyright © 2012, Intel Corporation. All rights reserved. 2 5/29/2012 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 Contents 1. Introduction............................................................................................................................................ 7 1.1 Introducing the Execution Unit ............................................................................................................. 7 1.2 EU Terms and Acronyms ..................................................................................................................... 9 1.3 EU Changes by Processor Generation .............................................................................................. 13 1.4 EU Notation ........................................................................................................................................ 13 2. EU Data Types ..................................................................................................................................... 15 2.1 Fundamental Data Types ................................................................................................................... 15 2.2 Numeric Data Types .......................................................................................................................... 15 2.2.1 Integer Numeric Data Types......................................................................................................... 16 2.2.2 Floating-Point Numeric Data Types.............................................................................................. 17 2.2.3 Packed Signed Half-Byte Integer Vector ...................................................................................... 18 2.2.4 Packed UnSigned Half-Byte Integer Vector ................................................................................. 18 2.2.5 Packed Restricted Float Vector .................................................................................................... 19 2.3 Floating Point Modes ......................................................................................................................... 21 2.3.1 IEEE Floating Point Mode ............................................................................................................ 21 2.3.2 Alternative Floating Point Mode.................................................................................................... 25 2.4 Type Conversion ................................................................................................................................ 26 2.4.1 Float to Integer ............................................................................................................................. 26 2.4.2 Integer to Integer with Same or Higher Precision......................................................................... 27 2.4.3 Integer to Integer with Lower Precision ........................................................................................ 27 2.4.4 Integer to Float ............................................................................................................................. 27 2.4.5 Double Precision Float to Single Precision Float ......................................................................... 27 2.4.6 Single Precision Float to Double Precision Float ......................................................................... 28 3. Execution Environment ...................................................................................................................... 29 3.1 EU Overview ...................................................................................................................................... 29 3.2 Primary Usage Models ....................................................................................................................... 30 3.2.1 AOS and SOA Data Structures .................................................................................................... 30 3.2.2 SIMD4 Mode of Operation ............................................................................................................ 32 3.2.3 SIMD4x2 Mode of Operation ........................................................................................................ 33 3.2.4 SIMD16 Mode of Operation .......................................................................................................... 34 3.2.5 SIMD8 Mode of Operation ............................................................................................................ 36 3.3 Registers and Register Regions ........................................................................................................ 36 3.3.1 Register Files ................................................................................................................................ 36 3.3.2 GRF Registers .............................................................................................................................. 36 3.3.3 ARF Registers .............................................................................................................................. 37 3.3.4 Immediate ..................................................................................................................................... 57 3.3.5 Region Parameters ....................................................................................................................... 57 3.3.6 Region Addressing Modes ........................................................................................................... 62 3.3.7 Access Modes .............................................................................................................................. 67 3.3.8 Execution Data Type .................................................................................................................... 68 3.3.9 Register Region Restrictions ........................................................................................................ 68 3.3.10 Destination Operand Description................................................................................................ 72 3.4 SIMD Execution Control ..................................................................................................................... 73 3.4.1 Predication .................................................................................................................................... 73 3.4.2 No Predication .............................................................................................................................. 74 3.4.3 Predication with Horizontal Combination ...................................................................................... 74 3.4.4 Predication with Vertical Combination .......................................................................................... 76 3.5 End of Thread .................................................................................................................................... 76 3.6 Assigning Conditional Flags ............................................................................................................... 77 3.7 Destination Hazard ............................................................................................................................. 79 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 3 3.8 Non-present Operands....................................................................................................................... 80 3.9 Instruction Prefetch ............................................................................................................................ 80 4. Exceptions ........................................................................................................................................... 81 4.1 Exception-Related Architecture Registers ......................................................................................... 81 4.2 System Routine .................................................................................................................................. 82 4.2.1 Invoking the System Routine ........................................................................................................ 82 4.2.2 Returning to the Application Thread ............................................................................................. 83 4.2.3 System IP (SIP) ............................................................................................................................ 84 4.2.4 System Routine Register Space................................................................................................... 84 4.2.5 System Scratch Memory Space ................................................................................................... 84 4.2.6 Conditional Instructions Within the System Routine .................................................................... 85 4.2.7 Use of NoDDClr ............................................................................................................................ 85 4.3 Exception Descriptions....................................................................................................................... 86 4.3.1 Illegal Opcode ............................................................................................................................... 86 4.3.2 Undefined Opcodes ...................................................................................................................... 86 4.3.3 Software Exception ....................................................................................................................... 86 4.3.4 Context Save and Restore ........................................................................................................... 87 4.4 Events That Do Not Generate Exceptions ......................................................................................... 87 4.4.1 Illegal Instruction Format .............................................................................................................. 87 4.4.2 Malformed Message ..................................................................................................................... 87 4.4.3 GRF Register Out of Bounds........................................................................................................ 87 4.4.4 Hung Thread ................................................................................................................................. 88 4.4.5 Instruction Fetch Out of Bounds ................................................................................................... 88 4.4.6 FPU Math Errors ........................................................................................................................... 88 4.4.7 Computational Overflow ............................................................................................................... 88 4.5 System Routine Example ................................................................................................................... 88 5. Instruction Set Summary .................................................................................................................... 92 5.1 Instruction Set Characteristics ........................................................................................................... 92 5.1.1 5nstruction Operands and Register Regions ............................................................................... 92 5.1.2 Instruction Execution .................................................................................................................... 92 5.2 Instruction Machine Formats .............................................................................................................. 93 5.2.1 EU Instruction Formats ................................................................................................................. 96 5.2.2 Common Instruction Fields ......................................................................................................... 100 5.2.3 Instruction Operation Doubleword (DW0) .................................................................................. 105 5.2.4 Instruction Destination Doubleword (DW1) ................................................................................ 110 5.2.5 Instruction Source 0 Doubleword 2 (DW2) ................................................................................. 115 5.2.6 Instruction Source 1 Doubleword 3 (DW3) ................................................................................. 119 5.3 EU Compact Instructions ................................................................................................................. 122 5.3.1 EU Compact Instruction Format ................................................................................................. 123 5.4 Opcode Encoding ............................................................................................................................. 127 5.4.1 Move and Logic Instructions ....................................................................................................... 127 5.4.2 Flow Control Instructions ............................................................................................................ 128 5.4.3 Miscellaneous Instructions ......................................................................................................... 129 5.4.4 Parallel Arithmetic Instructions ................................................................................................... 130 5.4.5 Vector Arithmetic Instructions ..................................................................................................... 131 5.4.6 Special Instructions .................................................................................................................... 131 5.5 Native Instruction BNF ..................................................................................................................... 132 5.5.1 Instruction Groups ...................................................................................................................... 132 5.5.2 Destination Register ................................................................................................................... 134 5.5.3 Source Register .......................................................................................................................... 134 5.5.4 Address Registers ...................................................................................................................... 135 5.5.5 Register Files and Register Numbers ........................................................................................ 135 5.5.6 Relative Location and Stack Control .......................................................................................... 137 5.5.7 Regions ....................................................................................................................................... 137 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 4 5.5.8 Types .......................................................................................................................................... 137 5.5.9 Write Mask .................................................................................................................................. 137 5.5.10 Swizzle Control ......................................................................................................................... 138 5.5.11 Immediate Values ..................................................................................................................... 138 5.5.12 Predication and Modifiers ......................................................................................................... 138 5.5.13 Instruction Options .................................................................................................................... 139 5.6 Instruction Set Summary Tables ...................................................................................................... 139 5.7 Accumulator Restrictions ................................................................................................................. 142 6. Instruction Set Reference ................................................................................................................. 145 6.1 Conventions ..................................................................................................................................... 145 6.1.1 Pseudo Code Format ................................................................................................................. 145 6.1.2 General Macros and Definitions ................................................................................................. 145 6.2 Evaluate Write Enable...................................................................................................................... 146 6.3 Instruction Description ...................................................................................................................... 147 6.4 add – Addition .................................................................................................................................. 147 6.5 addc – Integer Addition with Carry ................................................................................................... 148 6.6 and – Logic And ............................................................................................................................... 149 6.7 asr – Arithmetic Shift Right .............................................................................................................. 150 6.8 avg – Average .................................................................................................................................. 151 6.9 bfe – Bit Field Extract ....................................................................................................................... 152 6.9.1 bfi1 – Bit Field Insert 1 ................................................................................................................ 153 6.10 bfi2 – Bit Field Insert 2 .................................................................................................................... 154 6.11 bfrev – Reverse Bits ....................................................................................................................... 155 6.12 brc – Branch Converging ................................................................................................................ 156 6.13 brd – Branch Diverging ................................................................................................................... 157 6.14 break – Break ................................................................................................................................. 159 6.15 call – Call ........................................................................................................................................ 160 6.16 cbit – Count Bits Set ....................................................................................................................... 162 6.17 cmp – Compare .............................................................................................................................. 163 6.18 cmpn – Compare NaN .................................................................................................................... 165 6.19 cont – Continue ............................................................................................................................... 166 6.20 dp2 – Dot Product 2 ........................................................................................................................ 167 6.21 dp3 – Dot Product 3 ........................................................................................................................ 168 6.22 dp4 – Dot Product 4 ........................................................................................................................ 169 6.23 dph – Dot Product Homogeneous .................................................................................................. 170 6.24 else – Else ...................................................................................................................................... 171 6.25 endif – End If ................................................................................................................................... 172 6.26 f16to32 – Half Precision Float to Single Precision Float ................................................................ 173 6.27 f32to16 – Single Precision Float to Half Precision Float ................................................................ 174 6.28 fbh – Find First Bit from MSB Side ................................................................................................. 175 6.29 fbl – Find First Bit from LSB Side ................................................................................................... 177 6.30 frc – Fraction ................................................................................................................................... 178 6.31 halt – Halt ........................................................................................................................................ 179 6.32 if – If ................................................................................................................................................ 180 6.33 illegal – Illegal ................................................................................................................................. 182 6.34 jmpi – Jump Indexed....................................................................................................................... 183 6.35 line – Line ....................................................................................................................................... 184 6.36 lrp – Linear Interpolation ................................................................................................................. 185 6.37 lzd – Leading Zero Detection .......................................................................................................... 186 6.38 mac – Multiply Accumulate ............................................................................................................. 187 6.39 mach – Multiply Accumulate High .................................................................................................. 188 6.40 mad – Multiply Add ......................................................................................................................... 189 6.41 math – Extended Math Function ..................................................................................................... 190 6.41.1 INV - Inverse ............................................................................................................................. 192 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 5 6.41.2 LOG – Logarithm ...................................................................................................................... 192 6.41.3 EXP - Exponent ........................................................................................................................ 192 6.41.4 SQRT ........................................................................................................................................ 192 6.41.5 RSQ .......................................................................................................................................... 193 6.41.6 POW ......................................................................................................................................... 193 6.41.7 SIN ............................................................................................................................................ 194 6.41.8 COS .......................................................................................................................................... 194 6.41.9 INT DIV ..................................................................................................................................... 194 6.41.10 mov – Move ............................................................................................................................ 195 6.42 6movi – Move Indexed.................................................................................................................... 196 6.43 mul – Multiply .................................................................................................................................. 197 6.44 nop – No Operation ........................................................................................................................ 200 6.45 not – Logic Not ................................................................................................................................ 201 6.46 or – Logic Or ................................................................................................................................... 202 6.47 pln – Plane ...................................................................................................................................... 203 6.48 ret – Return ..................................................................................................................................... 204 6.49 rndd – Round Down ........................................................................................................................ 205 6.50 rnde – Round to Nearest or Even ................................................................................................... 206 6.51 rndu – Round Up ............................................................................................................................ 208 6.52 rndz – Round to Zero ...................................................................................................................... 209 6.53 sad2 – Sum of Absolute Difference 2 ............................................................................................. 211 6.54 sada2 – Sum of Absolute Difference Accumulate 2 ....................................................................... 212 6.55 sel – Select ..................................................................................................................................... 213 6.56 send Message ................................................................................................................................ 214 6.57 sendc – Conditional Send Message ............................................................................................... 218 6.58 shl – Shift Left ................................................................................................................................. 219 6.59 shr – Shift Right .............................................................................................................................. 220 6.60 subb – Integer Subtraction with Borrow.......................................................................................... 221 6.61 wait – Wait Notification ................................................................................................................... 222 6.62 while – While ................................................................................................................................... 223 6.63 xor – Logic Xor ................................................................................................................................ 224 7. EU Programming Guide .................................................................................................................... 225 7.1 Assembler Pragmas ......................................................................................................................... 225 7.2 Declarations ..................................................................................................................................... 225 7.2.1 Defaults and Defines .................................................................................................................. 225 7.2.2 Example Pragma Usages ........................................................................................................... 226 7.2.3 Assembly Programming Guideline ............................................................................................. 228 7.3 Usage Examples .............................................................................................................................. 228 7.3.1 Vector Immediate ....................................................................................................................... 228 7.3.2 Destination Mask for DP4 and Destination Dependency Control ............................................... 230 7.3.3 Null Register as the Destination ................................................................................................. 231 7.3.4 Use of LINE Instruction ............................................................................................................... 231 7.3.5 Mask for SEND Instruction ......................................................................................................... 232 7.3.6 Flow Control Instructions ............................................................................................................ 235 7.3.7 Execution Masking ..................................................................................................................... 237 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 6 1. Introduction This chapter contains these sections that introduce this volume.  Introducing the Execution Unit  EU Terms and Acronyms  EU Changes by Processor Generation  EU Notation Subsequent chapters cover:  EU Data Types  Execution Environment  Exceptions  Instruction Set Summary  Instruction Set Reference  EU Programming Guide The EU Programming Guide provides some useful examples and information but is not a complete or comprehensive programming guide. 1.1 Introducing the Execution Unit This section introduces the Execution Unit (EU), a simple and capable processor within the GPU that supports graphics processing within the graphics pipelines, can do general purpose computing (GPGPU), and responds to exceptional conditions via the System Routine. The EU provides parallelism at two levels: thread and data element. Multiple threads can execute on the EU; the number executing concurrently depends on the processor and is transparent to EU code. Each thread has its own registers (GRF and ARF, described below). Most EU instructions operate on arrays of data elements; the number of data elements is normally the ExecSize (execution size) or number of channels for the instruction. A channel is a logical unit of execution for data element access, masking, and flow control within instructions. The number of channels is independent of the number of physical ALUs or FPUs for a particular graphics processor. EU native instructions are 128 bits (16 bytes) wide. Some combinations of instruction options can use compact instruction formats that are 64 bits (8 bytes) wide. Identifying instructions that can be compacted and creating the compact representations is done by software tools, including compilers and assemblers. Data manipulation instructions have a destination operand (dst) and one, two, or three source operands (src0, src1, or src2). The instruction opcode determines the number of source operands. An instruction's last source operand can be an immediate value rather than a register. Data read or written by a thread is generally in the thread's GRF (General Register File), 128 general registers, each 32 bytes. A data element address within the GRF is denoted by a register number (r0 to r127) and a subregister number. In the instruction syntax, subregister numbers are in units of data element size. For example, a :d (Signed Doubleword Integer) element can be in subregister 0 to 7, corresponding to byte numbers in the instruction encoding of 0, 4, ... 28. Note: The EU cannot directly read or write data in system memory. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 7 Specialized registers used to implement the ISA are in a distinct per thread Architecture Register File (ARF). Each such register or group of related registers has its own distinct name. For example, ip is the instruction pointer and f0 is a flags register. An ARF register can be a src0 or dst operand but not a src1 or src2 operand. There are restrictions on how particular ARF registers are accessed that should be understood before directly reading or writing those registers. See the ARF Registers section for more information. The EU supports both integer and floating-point data types, as described in the Numeric Data Types section. For EU flow control, each channel has its own per-channel instruction pointer (PcIP[n]) and only executes an instruction when IP == PcIP[n] and any other masks enable the channel. Most flow control instructions use signed offsets from the current instruction address to reference their targets. Unconditional branches are done using mov with IP as the destination. Flow control can also use SPF (Single Program Flow) mode to execute with a single instruction pointer (IP). The EU ISA supports predication, masking, regioning, swizzling, some type conversions, source modification, saturation, accumulator updates, and flag updates as part of instruction execution:  Predication creates a bit mask (PMask) to enable or disable channels for a particular instruction execution. Pmask is derived from flag register and subregister values using boolean formulas determined by the PredCtrl (Predicate Control) and PredInv (Predicate Inversion) instruction fields. See the Predication section.  Masking is the overall process of determining which channels execute for a given instruction based on five factors:  Number of channels (only channels in [0, ExecSize - 1] can execute)  Execution mask (EMask)  Whether the channel is on the instruction (if not in Single Program Flow mode and MaskCtrl is not NoMask)  Predicate mask (PMask)  In Align16 mode, any enabling of channels using the Dst.ChanEn instruction field (if MaskCtrl is not NoMask).  Regioning specifies an array of data elements contained in one or two registers, with options for scattering, interleaving, or repeating data elements in registers using width and stride values, subject to significant constraints. Regioning also includes access mode (Align1 or Align16) and addressing mode (Direct or Indirect). See the Registers and Register Regions section.  Swizzling allows small scale reordering of data elements within groups of four at the input using the modulo 4 channel names x, y, z, and w. For example, a swizzle of .wzyx with an ExecSize of 8 reads execution channels 0 to 7 from these input channels: 3, 2, 1, 0, 7, 6, 5, and 4. Swizzling is only available in the Align16 access mode, described in the Execution Environment chapter.  Type Conversions do any needed conversion from source data type to execution data type and from execution data type to destination data type. See Execution Data Type for more information. Each instruction description indicates what combinations of data types are supported.  Source Modification modifies a source operand just before doing the requested operation. For a numeric operation, the choices are:  No modification (normal).  - indicating negation.  (abs) indicating absolute value.  -(abs) indicating a forced negative value. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 8 Source modification logically occurs after any conversion from source data type to execution data type. Each instruction description indicates whether it supports source modification.  Saturation clamps result values to the nearest value within a saturation range determined by the destination type. For a floating-point type, the saturation range is [0.0, 1.0]. For an integer type, the saturation range is the entire range for that type, for example [0, 65535] for the UW (Unsigned Word) type. Each instruction description indicates whether it supports saturation.  Accumulator Updates optionally update the accumulator register or registers in the ARF with destination values as a side effect of instruction execution. The AccWrCtrl instruction field enables accumulator updates. The Accumulator Disable flag in control register 0 (cr0) can be used to disable accumulator updates, regardless of AccWrCtrl values; for example, this flag may be used in the System Routine.  Flag Updates optionally update a flags register and subregister (f0.0, f0.1, f1.0, or f1.1) with conditional flags based on the CondModifier (Condition Modifier) instruction field. For example, a CondModifier of .nz (not zero) assigns flag bits based on whether result elements are not zero (1) or zero (0). Each instruction description indicates whether it supports the Condition Modifier and any restrictions on the values supported. Note: The EU is not required to execute steps in its internal pipeline sequentially or in order, so long as it produces correct results. The assembler syntax uses spaces between operands and encloses ExecSize and any predicate in parentheses. Instruction mnemonics, register names, conditional modifiers, predicate controls, and type designators use lowercase. Function names used with the math instruction are UPPERCASE. ( pred ) inst cmod sat ( exec_size ) dst src0 src1 { inst_opt, ... } General register destination regions use the syntax rm.n:type. General register directly addressed source regions use the syntax rm.n:type. You need to understand more about register regioning to understand all of these terms. The following example assembly language instruction adds two packed 16-element single-precision Float arrays in r4/r5 and r2/r3 writing results to r0/r1, only on those channels enabled by the predicate in f0.0 along with any other applicable masks. (f0.0) add (16) r0.0<1>:f r2.0<8;8,1>:f r4.0<8;8,1>:f 1.2 EU Terms and Acronyms This section provides three tables describing EU general terms and acronyms, EU data types, and EU selected ARF registers. EU General Terms and Acronyms Term Description ALT mode A floating-point execution mode that maps +/- inf to +/- fmax, +/- denorm to +/-0, and NaN to +0 at the FPU inputs and never produces infinities, denormals, or NaN values as outputs. See IEEE mode. ALU Arithmetic Logic Unit. A functional block that performs integer arithmetic and logic operations, as distinct from instruction fetch and decode, floating-point operations (see FPU), or messaging. AOS Array Of Structures. Also see SOA. ARF Architecture Register File, a distinct register file containing registers used to implement specific ISA features. For example the Instruction Pointer and condition flags are in ARF registers. See GRF. byte An 8-bit value aligned on an 8-bit boundary and the basic unit of addressing. Bits within a byte are denoted 0 to 7 from LSB to MSB. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 9 Term Description channel A logical unit of SIMD data parallel execution within a thread and within the EU. The number of physical ALUs or FPUs is not directly related to the number of channels. Supports up to 16 channels. Supports up to 32 channels. compact A 64-bit instruction encoded as described in the EU Compact Instructions section. Only some instruction combinations of instruction parameters can be encoded as compact instructions. See native instruction. compressed An instruction that writes to two destination registers. For example a SIMD16 instruction with Float instruction operands can write channels 0 to 7 to one 32-byte general register and channels 8 to 15 to a second, consecutive 32-byte general register. denorm A very small but nonzero number in IEEE mode, with a magnitude less than the smallest normalized floating-point number representable in a particular floating-point format. Denormals lose precision as their values approach zero, called gradual underflow. DWord Doubleword. A 32-bit (4-byte) value aligned on a 32-bit (4-byte) boundary. Bits within a DWord are denoted 0 to 31 from LSB to MSB. EOT End of Thread. A flag set on a send or sendc instruction to terminate a thread's execution on the EU. EU Execution Unit. The single GPU unit described in this volume. This volume describes individual data parallel execution paths within a thread in the EU as channels. A few fields, like EUID, use EU to refer to a particular hardware resource used to implement the overall EU. exception An error or interrupt condition that arises during execution that may transfer control to the System Routine. Some exceptions can be disabled, preventing such transfers. As defined in this volume, some errors do not produce exceptions. ExecSize The number of execution channels for a particular instruction. Channels within that number are enabled or disabled by various masks. floating-point Numeric types that allow fractional values and often a wider range than integer types. The EU supports binary floating-point types including the single precision type and the double precision typedefined by the IEEE 754 standard. GEN GEN is sometimes used to refer to Intel's mainstream GPU architecture integrated with recent CPU generations. GRF General Register File, a distinct register file containing 128 general registers, r0 to r127. Each general register is 256 bits (32 bytes), can contain any type of data, and can be accessed with any valid combination of addressing mode, access mode, and region parameters. A general register is directly addressed using a register number and subregister number, or indirectly addressed using an address subregister (index register) and an address immediate offset. IEEE mode A floating-point execution mode that supports all the kinds of floating-point values described by the IEEE 754 standard: normalized finite nonzero binary floating-point numbers, signed zeros, signed infinities, signed denormals that are closer to zero than any normalized value but still nonzero, and NaN (not a number) values. See ALT mode. index register An address subregister when used for indirect addressing. inf Infinity, +inf or -inf, as a floating-point value in IEEE mode. instruction In this volume, instruction always refers to an EU instruction. ISA Instruction Set Architecture, processor aspects visible to programs and programmers and independent of a particular implementation, including data types, registers, memory access, addressing modes, exceptions, instruction encodings, and the instruction set itself. An ISA does not include instruction timing, hardware pipeline details, or the number of physical resources (ALUs, FPUs, instruction decoders) mapped to logical constructs (threads, channels). This volume also includes a recommended assembly language syntax, closely related to the ISA but logically distinct from it. LSB Least significant bit. message A data structure transmitted from a thread to another thread, to a shared function, or to a fixed function. Message passing is the primary communication mechanism of the GEN architecture. MSB Most significant bit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 10 Term Description NaN Not a Number. A non-numeric value allowed in the standard single precision and double precision floating-point number formats. Quiet NaNs propagate through calculations and signaling NaNs cause exceptions. NaNs are not used in the ALT floating-point mode. native A 128-bit instruction, the regular instruction format that allows all defined instruction parameters and instruction options. Some instructions can also be encoded using a 64-bit compact instruction format. OWord Octword. A 128-bit (16-byte) value aligned on a 128-bit (16-byte) boundary. Bits within an OWord are denoted 0 to 127 from LSB to MSB. This term is used rarely and may be dropped from future versions of this volume. packed A register region is described as packed if its elements are adjacent in memory, with no intervening space, no overlap, and no replicated values. If there is more than one element in a row, elements must be adjacent. If there is more than one row, rows must be adjacent. When two registers are used, the registers must be adjacent and both must exist. The immediate vector data types are all described as Packed because each such type packs several small data elements into a 32-bit immediate value. QWord Quadword. A 64-bit (8-byte) value aligned on a 64-bit (8-byte) boundary. Bits within a QWord are denoted 0 to 63 from LSB to MSB. region A collection of data locations in registers and subregisters for a source or destination operand. The associated regioning parameters allow regions to be arrays with various layouts. register Part of the directly accessible state of an EU program, such as a general register in the GRF or an architecture register in the ARF. Note that system memory is not directly accessible. SIMD Single Instruction Multiple Data. Each EU instruction can operate on multiple data elements in parallel, as specified by the instruction's ExecSize. SIP System Instruction Pointer, the starting IP value for the System Routine. SOA Structure of Arrays. Also see AOS. SPF Single Program Flow. A mode in which every execution channel uses the common instruction pointer, IP in the ip register. The SPF bit in the control register is 1 to enable SPF and 0 to disable it. If SPF is disabled, then each execution channel n has its own instruction pointer, PcIP[n] and each channel n is only eligible to execute, subject to other masking, when PcIP[n] == IP. swizzle Rearrange data elements within a vector. The EU supports modulo four swizzling of register source operands at the input in the Align16 access mode. System A global EU exception handling routine. Any enabled exception from any EU thread transfers control Routine to this routine. thread An instance of a program executing on the EU. The life cycle for a thread on the EU starts with the first instruction after being dispatched to the EU by the Thread Dispatcher and ends after executing a send or sendc instruction with EOT set, signaling thread termination. Threads can be independent or can communicate with each other via the Message Gateway shared function. word A 16-bit (2-byte) value aligned on a 16-bit (2-byte) boundary. Bits within a word are denoted 0 to 15 from LSB to MSB. Word has denoted a 16-bit unit for Intel processors since the 8086 and 8088 processors were introduced in 1978. The next table lists all EU numeric data types. See the Numeric Data Types section for more information about each data type. EU Numeric Data Types (Listed Alphabetically by Short Name) Size Size Integral Short Assembler Long in in or Name Syntax Name Bytes Bits Float Description B :b Signed Byte Integer 1 8 I Signed integer in the range -128 to 127. D :d Signed Doubleword 4 32 I Signed integer in the range -231 to 231 - 1. Integer DF :df Double Float 8 64 F Double precision floating-point number. F :f Float 4 32 F Single precision floating-point number. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 11 Size Size Integral Short Assembler Long in in or Name Syntax Name Bytes Bits Float Description UB :ub Unsigned Byte Integer 1 8 I Unsigned integer in the range 0 to 255. UD :ud Unsigned Doubleword 4 32 I Unsigned integer in the range 0 to 232 - 1. Integer UV :uv Packed Unsigned Half 4 32 I Eight 4-bit unsigned integer values each in the Byte Integer Vector range 0 to 15. Only used as an immediate value. UW :uw Unsigned Word Integer 2 16 I Unsigned integer in the range 0 to 65,535. V :v Packed Signed Half Byte 4 32 I Eight 4-bit signed integer values each in the range - Integer Vector 8 to 7. Only used as an immediate value. VF :vf Packed Restricted Float 4 32 F Four 8-bit restricted float values. Only used as an Vector immediate value. W :w Signed Word Integer 2 16 I Signed integer in the range -32,768 to 32,767. The next table lists the seven ARF registers that you should understand first, omitting several others. See the ARF Registers section for more information, including descriptions of additional registers not listed below. EU Selected ARF Registers (Listed Alphabetically by Name) Assembler Name Syntax Description Accumulators acc0, acc1 Data registers that can hold integer or floating-point values of various sizes. Many instructions can implicitly update accumulators with a copy of destination values, done by setting the AccWrCtrl instruction option. A few instructions, like mac (Multiply Accumulate), use the accumulators as an implicit source operand, useful for some iterative calculations. Address a0.s Holds subregisters primarily used for indirect addressing. Each subregister is a 16-bit Register UW (Unsigned Word) value. For an indirectly addressed operand or element, the subregister value plus an AddrImm signed offset field determines the byte address (RegNum and SubRegNum) within the register file (GRF ). There are 8 address subregisters. Control cr0.s Contains bit fields for floating-point modes, flow control modes, and exception Register enable/disable. Also contains exception indicator flags and saves the AIP (Application Instruction Pointer) on transferring control to the System Routine to handle an exception. Flags fr.s Used as the outputs for various channel conditional signals, such as equality/zero or overflow. Used as the inputs for predication. There are two 32-bit flags registers each containing two 16-bit subregisters. Instruction ip References the current instruction in memory, as an unsigned offset from the General Pointer State Base Address. IP is the thread's overall instruction pointer. Each channel n can (IP) have its own instruction pointer (PcIP[n]). If not in Single Program Flow mode (SPF is 0) then only those channels where PcIP[n] == IP are eligible to execute the instruction, if enabled by all other applicable masks. Null Register null Indicates a non-existent operand. Unused operands in the instruction format, like the unused second source operand field in a mov instruction, are encoded as null. For present source operands, reading a null source operand returns undefined values. For null destination operands, results are discarded but any implicit updates to accumulators or flags still occur. State Register sr0.s Contains thread identification and scheduling fields, and mask fields for enabling or Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 12 Assembler Name Syntax Description disabling channels. 1.3 EU Changes by Processor Generation This section describes how the EU changes for particular processor generations. Instruction compaction tables can differ for each generation, so that is not mentioned in these lists. Particular readers and audiences can see only certain content in this section. Errata and workarounds for particular generations, SKUs, or steppings are not included in these lists. Some small changes in instruction layouts are not included in these lists. Ivy Bridge These features or behaviors are added , continuing to later generations:  The maximum ExecSize increases to 32, for byte or word operands.  Increase the number of flag registers from one to two.  Add the NibCtrl field, used with QtrCtrl to select groups of channels or flags.  Add the DF (Double Float) data type, the first time an 8-byte data type is supported. DF only supports the IEEE floating-point mode and not the ALT floating-point mode.  Add a shared source data type field and a destination data type field for instructions with three source operands, allowing F (Float), DF (Double Float), D (Signed Doubleword Integer), or UD (Unsigned Doubleword Integer) types to be specified.  Add bit manipulation instructions: bfi1, bfi2, bfrev, cbit, fbh, and fbl.  Add the integer addc (Add with Carry) and subb (Subtract with Borrow) instructions.  Add the brc (Branch Converging) and brd (Branch Diverging) instructions.  For the cmp and cmpn instructions, relax the accumulator restrictions.  For the sel instruction, remove the accumulator restriction.  Add the Rounding Mode and Double Precision Denorm Mode fields in Control Register 0. These features or behaviors are specific to and may not continue to later generations:  Each DF (Double Float) operand uses an element size of 4 rather than 8 and all regioning parameters are twice what the values would be based on the true element size: ExecSize, Width, HorzStride, and VertStride. Each DF operand uses a pair of channels and all masking and swizzling should be adjusted appropriately.  The f16to32 and f32to16 instructions convert between half-precision float and Float.  The mul instruction limits integer multiplication involving DWords so that only the low 16 bits of src1 are used even if src1 is a DWord.  The sel (Select) instruction does not support an ExecSize of 32.  SIMD16 execution on DWords is not allowed when an accumulator is an explicit source or destination operand. 1.4 EU Notation The Courier New font is used for code examples and for the Syntax, Format, and Pseudocode sections in the instruction reference. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 13 The italic font style is used for instruction mnemonics outside of code (e.g., the send instruction), for syntactic production names, for key values in algorithms (ExecSize), and to emphasize a word or phrase. For example: When bit 10 is set, the destination register scoreboard is not cleared. The bold font weight is used for the short name and long name of a bit field being described, for value names being defined, for syntactic terminals, for unnumbered subheadings, and for the terms Note, Erratum/Errata, or Workaround used to introduce a paragraph. Bit field names and value names used where not being defined and not as syntactic terminals are in plain text. Bit field values in hex use the 0x prefix. The BSpec currently uses the 0x prefix for hex in some parts and the h suffix for hex in other parts. For single bits, values appear as simply 0 or 1. For multi-bit binary values, the appropriate number of binary digits appears with a b suffix. Instruction mnemonics are lowercase. Function names invoked using the math instruction are UPPERCASE. For example, SQRT. Tables describing bit field layouts or registers proceed from most significant to least significant bits. Figures showing bit fields or registers show most significant bits on the left and least significant bits on the right. Any bit, field, or register described as Reserved should be regarded as undefined and unpredictable. Such bits should be treated as follows:  When testing values, do not depend on the state of reserved bits. Mask out or otherwise ignore such bits.  Sometimes software must initialize reserved bits. For example, a compiler must write complete instruction values when creating an instruction stream, including reserved bits. In such cases, write reserved bits as zeros unless otherwise indicated.  Do not use reserved bits as extra storage for software-defined values; put nothing in such bits.  When saving state and restoring state, save and restore any reserved bits as well.  Do not assume that reserved bits are invariant between explicit writes. Software should function even if reserved bits change in undefined and unpredictable ways. Any value, encoding, or combination of values or encodings described as Reserved must not be used. The EU's behavior is undefined in this case. When a combination of instruction parameters or an EU state is described as producing undefined results or behavior, do not assume that undefined results or behavior are confined to specific instructions, operands, registers, or channels. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 14 2. EU Data Types 2.1 Fundamental Data Types The fundamental data types in the GEN architecture are halfbyte, byte, word, doubleword (DW), quadword (QW), double quadword (DQ) and quad quadword (QQ). They are defined based on the number of bits of the data type, ranging from 4 bits to 256 bits. As shown in Fundamental Data Types, a halfbyte contains 4 bits, a byte contains 8 bits, a word contains two bytes, and a doubleword (dword) contains two words, and so on. Halfbyte is a special data type such that it cannot be accessed directly as standalone data element. It is only allowed as a subfield of the numeric data type of “packed signed halfbyte integer vector” described in the next section. Fundamental data types With the exception of halfbyte, the access of a data element to/from a GEN register or to/from memory must be aligned on the natural boundaries of the data type. The natural boundary for a word has an even- numbered address in unit of byte. The natural boundary for a doubleword has an address divisible by 4 bytes. Similarly, the natural boundary for a quadword, double quadword and quad quadword has an address divisible by 8, 16, and 32 bytes, respectively. Quadword, double quadword and quad quadword do not have corresponding numeric data type. Instead, they are used to describe a group (a vector) of numeric data elements of smaller size align to larger natural boundaries. 2.2 Numeric Data Types The numeric data types defined in the GEN architecture include signed and unsigned integers and floating-point numbers (floats) of various sizes. These numeric data types are described below. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 15 2.2.1 Integer Numeric Data Types The Execution Unit supports the following integer data types. Signed integer types use two's complement representation for negative numbers. UB: Unsigned Byte, 8-bit Unsigned Integer 7 0 B: Byte, 8-bit Signed Integer 76 0 S UW: Unsigned Word, 16-bit Unsigned Integer 1 5 0 W: Word, 16-bit Signed Integer 11 54 0 S UD: Unsigned Doubleword, 32-bit Unsigned Integer 3 1 0 D: Doubleword, 32-bit Signed Integer 33 10 0 S UV: Packed Unsigned Half-Byte Integer Vector, 8 x 4-Bit Unsigned Integer 3 2 2 2 2 2 1 1 1 1 1 1 8 7 4 3 0 9 6 5 2 1 8 7 4 3 0 V: Packed Signed Half-Byte Integer Vector, 8 x 4-Bit Signed Integer 3 2 2 2 2 2 1 1 1 1 1 1 8 7 4 3 0 9 6 5 2 1 8 7 4 3 0 S S S S S S S S The following table summarizes the EU integer data types. Execution Unit Integer Data Types Notation Size in Bits Name Range UB 8 Unsigned Byte Integer [0, 255] B 8 Signed Byte Integer [-128, 127] UW 16 Unsigned Word Integer [0, 65535] W 16 Signed Word Integer [-32768, 32767] Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 16 Notation Size in Bits Name Range UD 32 Unsigned Doubleword Integer [0, 232 – 1] D 32 Signed Doubleword Integer [–231, 231 – 1] UV 32 Packed Unsigned Half-Byte [0, 15] in each of eight 4-bit immediate vector elements. Integer Vector V 32 Packed Signed Half-Byte [-8, 7] in each of eight 4-bit immediate vector elements. Integer Vector Restriction: Only a raw move using the mov instruction supports a packed byte destination register region. For information about raw moves, refer to the Description in mov – Move. 2.2.2 Floating-Point Numeric Data Types The Execution Unit supports the following floating-point data types. The Float and Double Float types use the single precision and double precision formats specified in IEEE Standard 754-1985 for Binary Floating-Point Arithmetic. In the ALT floating-point mode, representations for infinities, denorms, and NaNs within those formats are not used. The EU does not support the double extended precision (80-bit) floating-point format found in the x86/x87/Intel 64 floating-point registers. All floating-point formats are signed using signed magnitude representation (a distinct sign bit, separate from the magnitude information). The F (Float) type supports both the ALT and IEEE floating-point modes, controlled by the Single Precision Floating-Point Mode bit in the Control Register. In IEEE mode, F calculations flush denormalized values to zero and gradual underflow is not supported. The DF (Double Float) type only supports the IEEE floating-point mode. Whether DF calculations support denorms or flush denormalized values to zero is controlled by the Double Precision Denorm Mode bit in the Control Register. F: Float, 32-bit Single-Precision Floating-Point Number 3 3 2 2 1 0 3 2 0 S biased fraction exponent DF: Double Float, 64-bit Double-Precision Floating-Point Number+ 6 6 5 5 3 2 2 1 0 S biased exponent fraction VF: Packed Restricted Float Vector, 4 x 8-Bit Restricted Precision Floating-Point Number 3 3 2 2 2 2 2 2 1 1 1 1 1 1 1 0 8 7 4 3 2 0 9 6 5 4 2 1 8 7 6 4 3 0 S b. exp. frac. S b. exp. frac. S b. exp. frac. S b. exp. frac. The following table summarizes the EU floating-point data types. Execution Unit Floating-Point Data Types Size in Notation Bits Name Range F 32 Float Single precision, 1 sign bit, 8 bits for the biased exponent, and 23 bits for the significand: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 17 Size in Notation Bits Name Range [–(2–2-23)127…–2-149, 0.0, 2-149… (2–2-23)127] DF 64 Double Float Double precision, 1 sign bit, 11 bits for the biased exponent, and 52 bits for the significand: [–(2–2-52)1023…–2-1074, 0.0, 2-1074… (2–2-52)1023] VF 32 Packed Restricted precision. Each of four 8-bit immediate vector elements has 1 sign Restricted bit, Float Vector 3 bits for the biased exponent (bias of 3), and 4 bits for the significand: [–31…–0.125, 0, 0.125… 31] 2.2.3 Packed Signed Half-Byte Integer Vector A packed signed halfbyte integer vector consists of 8 signed halfbyte integers contained in a doubleword. Each signed halfbyte integer element has a range from -8 to 7 with the sign on bit 3. This numeric data type is only used by an immediate source operand of doubleword in a GEN instruction. It cannot be used for the destination operand or a non-immediate source operand. GEN hardware converts the vector into an 8-element signed word vector by sign extension. This is illustrated in Numeric Data Types. The short hand format notation for a packed signed half-byte vector is V. Converting a Packed Half-Byte Vector to a 128-bit Signed Integer Vector 2.2.4 Packed UnSigned Half-Byte Integer Vector A packed unsigned halfbyte integer vector consists of 8 unsigned halfbyte integers contained in a doubleword. Each unsigned halfbyte integer element has a range from 0 to 15. This numeric data type is only used by an immediate source operand of doubleword in a GEN instruction. It cannot be used for the Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 18 destination operand or a non-immediate source operand. GEN hardware converts the vector into an 8- element signed word vector. 2.2.5 Packed Restricted Float Vector A packed restricted float vector consists of 4 8-bit restricted floats contained in a doubleword. Each restricted float has the sign at bit 7, a 3-bit coded exponent in bits 4 to 6, a 4-bit fraction in bits 0 to 3, and an implied integer 1. The exponent is in excess-3 format – having a bias of 3. Restricted float provides zero, positive/negative normalized numbers with a small range (3-bit exponent) and small precision (4-bit fraction). This numeric data type is only used by an immediate source operand of doubleword in a GEN instruction. It cannot be used for the destination operand, or a non-immediate source operand. The following figure shows how to convert an 8-bit restricted float into a single precision float. Converting a 3-bit exponent with a bias of 3 to an 8-bit exponent with a bias of 127 is by adding 4, or equivalently copying bit 2 to bit 7 and putting the inverted bit 2 to bits 6:2. A special logic is also needed to take care of positive/negative zeros. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 19 Conversion from a Restricted 8-bit Float to a Single-Precision Float The following table shows all possible numbers of the restricted 8-bit float. Only normalized float numbers can be represented, including positive and negative zero, and positive and negative finite numbers. Normalized infinites, NaN, and denormalized float numbers cannot be represented by this type. It should be noted that this 8-bit floating point format does not follow IEEE-754 convention in describing numbers with small magnitudes. Specifically, when the exponent field is zero and the fraction field is not zero, an implied one is still present instead of taking a denormalized form (without an implied one). This results in a simple implementation but with a smaller dynamic range – the magnitude of the smallest non-zero number is 0.125. Examples of Restricted 8-bit Float Numbers Extended Floating Number Class Hex # Sign [7] Exponent [6:4] Fraction [3:0] 8-bit Exponent in Decimal Positive Normalized Float 0x70-0x7F 0 111 0000 … 1111 1000 0011 16 … 31 0x60-0x6F 0 110 0000 … 1111 1000 0010 8 … 15.5 0x50-0x5F 0 101 0000 … 1111 1000 0001 4 … 7.75 0x40-0x4F 0 100 0000 … 1111 1000 0000 2 … 3.875 0x30-0x3F 0 011 0000 … 1111 0111 1111 1 … 1.9375 0x20-0x2F 0 010 0000 … 1111 0111 1110 0.5 … 0.96875 0x10-0x1F 0 001 0000 … 1111 0111 1101 0.25 … 0.484375 0x01-0x0F 0 000 0001 … 1111 0111 1100 0.125 … 0.2421875 0x00 0 000 0000 0000 0000 0 (+zero) Negative Normalized Float 0xF0-0xFF 1 111 0000 … 1111 1000 0011 -16 … -31 0xE0-0xEF 1 110 0000 … 1111 1000 0010 -8 … -15.5 0xD0-0xDF 1 101 0000 … 1111 1000 0001 -4 … -7.75 0xC0-0xCF 1 100 0000 … 1111 1000 0000 -2 … -3.875 0xB0-0xBF 1 011 0000 … 1111 0111 1111 -1 … -1.9375 0xA0-0xAF 1 010 0000 … 1111 0111 1110 -0.5 … -0.96875 0x90-0x9F 1 001 0000 … 1111 0111 1101 -0.25 … -0.484375 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 20 Extended Floating Number Class Hex # Sign [7] Exponent [6:4] Fraction [3:0] 8-bit Exponent in Decimal 0x81-0x8F 1 000 0001 … 1111 0111 1100 -0.125 … -0.2421875 0x80 1 000 0000 0000 0000 -0 (-zero) The following figure shows the conversion of a packed exponent-only float to a 4-element vector of single precision floats. The shorthand format notation for a packed signed half-byte vector is VF. 2.3 Floating Point Modes GEN architecture supports two floating point operation modes, namely IEEE floating point mode (IEEE mode) and alternative floating point mode (ALT mode). Both modes follow mostly the requirements in IEEE-754 but with different deviations. The deviations will be described in details in later sections. The primary difference between these modes is on the handling of Infs, NaNs and denorms. The IEEE floating point mode may be used to support newer versions of 3D graphics API Shaders and the alternative floating point mode may be used to support early Shader versions. These two modes are supported by all units that perform floating point computations, including GEN execution units, GEN shared functions like Extended Math, the Sampler and the Render Cache color calculator, and fixed functions like VF, Clipper, SF and WIZ. Host software sets floating point mode through the fixed function state descriptors for 3D pipeline and the interface descriptor for media pipeline. Therefore different modes may be associated with different threads running concurrently. Floating point mode control for EU and shared functions are based on the floating point mode field (bit 0) of cr0 register. 2.3.1 IEEE Floating Point Mode 2.3.1.1 Partial Listing of Honored IEEE-754 Rules Here is a summary of expected 32-bit floating point behaviors in GEN architecture. Refer to IEEE-754 for topics not mentioned.  INF – INF = NaN  0 * (+/–)INF = NaN  1 / (+INF) = +0 and 1 / (–INF) = –0 o (+/–)INF / (+/–)INF = NaN as A/B = A * (1/B)  INV (+0) = RSQ (+0) = +INF, INV (–0) = RSQ (–0) = –INF, and SQRT (–0) = –0  RSQ (–finite) = SQRT (–finite) = NaN Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 21  LOG (+0) = LOG (–0) = –INF, LOG (–finite) = LOG (–INF) = NaN  NaN (any OP) any-value = NaN with one exception for min/max mentioned below. Resulting NaN may have different bit pattern than the source NaN.  Normal comparison with conditional modifier of EQ, GT, GE, LT, LE, when either or both operands is NaN, returns FALSE. Normal comparison of NE, when either or both operands is NaN, returns TRUE. o Note: Normal comparison is either a cmp instruction or an instruction with conditional modifier  Special comparison cmpn with conditional modifier of EQ, GT, GE, LT, LE, when the second source operand is NaN, returns TRUE, regardless of the first source operand, and when the second source operand is not NaN, but first one is, returns FALSE. Cmpn of NE, when the second source operand is NaN, returns FALSE, regardless of the first source operand, and when the second source operand is not NaN, but first one is, returns TRUE. o This is used to support the proposed IEEE-754R rule on min or max operations. For which, if only one operand is NaN, min and max operations return the other operand as the result.  Both normal and special comparisons of any non-NaN value against +/– INF return exact result according to the conditional modifier. This is because that infinities are exact representation in the sense that +INF = +INF and –INF = –INF. o NaN is unordered in the sense that NaN != NaN.  IEEE-754 requires floating point operations to produce a result that is the nearest representable value to an infinitely precise result, known as "round to nearest even" (RTNE). 32-bit floating point operations must produce a result that is within 0.5 Unit-Last-Place (0.5 ULP) of the infinitely precise result. This applies to addition, subtraction, and multiplication.  All arithmetic floating point instructions does Round To Nearest Even at the end of the computation, except the round instructions. 2.3.1.2 Complete Listing of Deviations or Additional Requirements vs. IEEE- 754 For a result that cannot be represented precisely by the floating point format, the EU uses rounding to nearest or even to produce a result that is within 0.5 Unit-Last-Place(0.5 ULP) of the infinitely precise result. The rounding mode is specified by the Rounding Mode field in the Control Register. The EU can report floating point overflow and NaN into conditional flags. Hewever, there is no support for floating point exceptions, status bits, or traps. ] handle denorms as follows:  Single precision (F, Float) denorms are flushed to sign-preserved zero on input and output of any floating-point mathematical operation.  Double precision (DF, Double Float) denorms are kept or flushed in mathematical operations based on the Double Precision Denorm Mode in the Control Register.  Denorms are not flushed for format conversions, irrespective of any denorm mode.  Denorms are not flushed for raw mov operations. For information about raw mov operations, refer to the Description in mov – Move. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 22  Input denorms are not flushed for half precision to single precision floating-point conversion. Other information regarding floating-point behaviors:  NaN input to an operation always produces NaN on output, however the exact bit pattern of the NaN is not required to stay the same (unless the operation is a raw “mov” instruction which does not alter data at all.)  x*1.0f must always result in x (except denorm flushed and possible bit pattern change for NaN).  x +/- 0.0f must always result in x (except denorm flushed and possible bit pattern change for NaN). But -0 + 0 = +0.  Fused operations (such as mac, dp4, dp3, etc.) may produce intermediate results out of 32-bit float range, but whose final results would be within 32-bit float range if intermediate results were kept at greater precision. In this case, implementations are permitted to produce either the correct result, or else ±inf. Thus, compatibility between a fused operation, such as mac, with the unfused equivalent, mul followed by add in this case, is not guaranteed.  As the accumulator registers have more precision than 32-bit float, any instruction with accumulator as a source/destination operand may produce a different result than that using GRF registers.  API Shader divide operations are implemented as x*(1.0f/y). With the two-step method, x*(1.0f/y), the multiply and the divide each independently operate at the 32-bit floating point precision level (accuracy to 1 ULP).  See the Type Conversion section for rules on converting to and from float representations. 2.3.1.3 Comparison of Floating Point Numbers The following tables detail the rules for floating point comparison. In the tables, “+/-Fin” stands for a positive or negative finite precision floating point number. Result is either a true (T) or false (F). Each row corresponds to a fixed src0 and each column corresponds to a fixed src1. When comparing two positive finite numbers (or two negative finite numbers), the result can be T or F depending on the values. Therefore, the corresponding fields in the following tables are marked as T/F. When comparing two double float numbers, the result can be T or F depending on the values and the denorm mode (enabled/disabled). The corresponding fields in the following tables are marked T/F*. Results of “Greater-Than” Comparison – CMP. src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -inf F F F F F F F F F -Fin T T/F F F F F F F F -denorm T T T/F* F F F F F F -0 T T T/F* F F F F F F +0 T T T/F* F F F F F F +denorm T T T/F* T/F* T/F* T/F* F F F +Fin T T T T T T T T/F F +inf T T T T T T T T F NaN F F F F F F F F F Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 23 Results of “Less-Than” Comparison – CMP.L src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN F T T T T T T T F -inf F T/F T T T T T T F -Fin F F T/F* T/F* T/F* T/F* T T F -denorm F F F F F T/F* T T F -0 F F F F F T/F* T T F +0 F F F F F T/F* T T F +denorm F F F F F F T/F T F +Fin F F F F F F F F F +inf F F F F F F F F F NaN Results of “Equal-To” Comparison – CMP.E src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -inf T F F F F F F F F -Fin F T/F F F F F F F F -denorm F F T/F* T/F* T/F* T/F* F F F -0 F F T/F* T T T/F* F F F +0 F F T/F* T T T/F* F F F +denorm F F T/F* T/F* T/F* T/F* F F F +Fin F F F F F F T/F F F +inf F F F F F F F T F NaN F F F F F F F F F Results of “Not-Equal-To” Comparison – CMP.NE src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -inf FALSE T T T T T T T T -Fin T T/F T T T T T T T -denorm T T T/F* T/F* T/F* T/F* T T T -0 T T T/F* FALSE FALSE T/F* T T T +0 T T T/F* FALSE FALSE T/F* T T T +denorm T T T/F* T/F* T/F* T/F* T T T +Fin T T T T T T T/F T T +inf T T T T T T T FALSE T NaN T T T T T T T T T Results of “Less-Than Or Equal-To” Comparison – CMP.LE src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -inf T T T T T T T T F -Fin F T/F T T T T T T F -denorm F F T/F* T/F* T/F* T/F* T T F Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 24 src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -0 F F T/F* T T T/F* T T F +0 F F T/F* T T T/F* T T F +denorm F F T/F* T/F* T/F* T/F* T T F +Fin F F F F F F T/F T F +inf F F F F F F F T F NaN F F F F F F F F F Results of “Greater-Than or Equal-To” Comparison – CMP.GE src0 src1 -inf -Fin -denorm -0 +0 +denorm +Fin +inf NaN -inf T F F F F F F F F -Fin T T/F F F F F F F F -denorm T T T/F* T/F* T/F* T/F* F F F -0 T T T/F* T T T/F* F F F +0 T T T/F* T T T/F* F F F +denorm T T T/F* T/F* T/F* T/F* F F F +Fin T T T T T T T/F F F +inf T T T T T T T T F NaN F F F F F F F F F 2.3.1.4 Min/Max of Floating Point Numbers A special comparison called Compare-NaN is introduced in the GEN architecture to handle the difference of above mentioned floating-point comparison and the rules on supporting MIN/MAX. To compute the MIN or MAX of two floating-point numbers, if one of the numbers is NaN and the other is not, MIN or MAX of the two numbers returns the one that is not NaN. When two numbers are NaN, MIN or MAX of the two numbers returns source1. Min and Max is supported by conditional select. Note even though f0.0 is specified in the instruction, the flag register is not touched by this instruction. The following tables detail the rules for this special compare-NaN operation for floating-point numbers. Notice that excepting “Not-Equal-To” comparison-NaN, last columns in all other tables have ‘T’. 2.3.2 Alternative Floating Point Mode The key characteristics of the alternative floating point mode is that NaN, Inf and denorm are not expected for an application to pass into the graphics pipeline, and the graphics hardware must not generate NaN, Inf or denorm as computation result. For example, a result that is larger than the maximum representable floating point number is expected to be flushed to the largest representable floating point number, i.e., +fmax. The fmax has an exponent of 0xFE and a mantissa of all one’s, which is the same for IEEE floating point mode. Note that this mode is applicable ONLY to Single Precision Float datatype. This also implies that ALT mode is not supported when Single precision datatype is involved in format conversion to double precision of half precision. Here is the complete list of the differences of legacy graphics mode from the relaxed IEEE-754 floating point mode.  Any +/- INF result must be flushed to +/- fmax, instead of being output as +/- INF. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 25  Extended mathematics functions of log(), rsq() and sqrt() take the absolute value of the sources before computation to avoid generating INF and NaN results. Alternative Floating Point Mode shows the support of these differences in various hardware units. Supported Legacy Float Mode and Impacted Units IEEE-754 Deviations VF Clipper SF WIZ EU EM Sampler RC Y Y Y Y Y Y Y Y Any +/- INF result flushed to +/- fmax Log, rsq, sqrt take abs() of sources N/A N/A N/A N/A N/A Y N/A N/A Alternative Floating Point Mode shows some of the desired or recommended alternative floating point mode behaviors that do not have hardware design impact. The reasons of not needing special hardware support for these items are also provided. This is based on the compliance requirement that can be found in the DirectX 9 specification: “Handling of NaNs, Infs, and denorms is undefined. Applications should not pass in such values into the graphics pipeline.” Dismissed legacy behaviors Suggested IEEE-754 Deviations Reason for Dismiss Mov forces (+/-)INF to (+/-)fmax (+/-)INF is never present as input (+/-)INF – (+/-)INF = +/- fmax instead of NaN (+/-)INF is never present as input Denorm must be flushed to zero in all cases (including Denorm is never present as input trivial mov and point sampling) Anything*0=0 (including NaN*0=0 and INF*0=0) NaN and INF are never present as input Except propagated NaN, NaN is never generated NaN is never present as input and GEN never generates NaN based on rules in the previous table An input NaN gets propagated excepting (a)-(d) NaN is never present as input (a) Rcp (and rsq) of 0 yields fmax N/A, as it is already covered by the general rule “Any +/- INF result flushed to +/- fmax” (b) Sampler honors 0/0 = 0 as if (1/0)*0 There is no divide in Sampler I Rcp (and rsq) of INF yields +/- 0 (+/-)INF is never present as input (d) Sampler honors INF/INF = 0 as if (1/INF)=0 There is no divide in Sampler followed by Anything*0 = 0 2.4 Type Conversion 2.4.1 Float to Integer Converting from float to integer is based on rounding toward zero. If the floating point value is +0, -0, +Denorm, -Denorm, +NaN –r -NaN, the resulting integer value is always 0. If the floating point value is positive infinity (or negative infinity), the conversion result takes the largest (or the smallest) represent- able integer value. If the floating point value is larger (or smaller) than the largest (or the smallest) represent-able integer value, the conversion result takes the largest (or the smallest) represent-able integer value. The following table shows these special cases. The last two rows are just examples. They can be any number outside the represent-able range of the output integer type (UD, D, UW, W, UB and B). Input Format Output Format F UD D UW W UB B +/- Zero 00000000 00000000 00000000 00000000 00000000 00000000 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 26 Input Format Output Format F UD D UW W UB B +/- Denorm 00000000 00000000 00000000 00000000 00000000 00000000 NAN 00000000 00000000 00000000 00000000 00000000 00000000 -NAN 00000000 00000000 00000000 00000000 00000000 00000000 INF FFFFFFFF 7FFFFFFF 0000FFFF 00007FFF 000000FF 0000007F -INF 00000000 80000000 00000000 00008000 00000000 00000080 FFFFFFFF 7FFFFFFF 0000FFFF 00007FFF 000000FF 0000007F +232 (*) 00000000 80000000 00000000 00008000 00000000 00000080 -232-1 (*) 2.4.2 Integer to Integer with Same or Higher Precision Converting an unsigned integer to a signed or an unsigned integer with higher precision is based on zero extension. Converting an unsigned integer to a signed integer with the same precision is based on modular wrap- around. Without saturation, a larger than represent-able number becomes a negative number. With saturation, a larger than represent-able number is saturated to the largest positive represent-able number. Converting a signed integer to a signed integer with higher precision is based on sign extension. Converting a signed integer to an unsigned integer with higher precision is based on sign extension. Without saturation, a negative number becomes a large positive number with the sign bit wrapped-up. With saturation, a negative number is saturated to zero. 2.4.3 Integer to Integer with Lower Precision Converting a signed or an unsigned integer to a signed or an unsigned integer with lower precision is based on bit truncation. Without saturation, only the lower bits are kept in the output regardless of the sign-ness of input and output. With saturation, a number that is outside the represent-able range is saturated to the closest represent-able value. 2.4.4 Integer to Float Converting a signed or an unsigned integer to a single precision float number is to round to the closest representable float number. For any integer number with magnitude less than or equal to 24 bits, resulting float number is a precise representation of the input. However, if it is more than 24 bits, by default a “round to nearest even” is performed. 2.4.5 Double Precision Float to Single Precision Float Converting a double precision floating-point number to a single precision floating-point number uses the round to zero rounding mode. Double Precision Float Single Precision Float -inf -inf -finite -finite/-denorm/-0 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 27 Double Precision Float Single Precision Float -denorm -0 -0 -0 +0 +0 +denorm +0 +finite +finite/+denorm/+0 +inf +inf NaN NaN The upper Dword of every Qword will be written with undefined value when converting DF to F. 2.4.6 Single Precision Float to Double Precision Float Converting a single precision floating-point number to a double precision floating-point number will produce a precise representation of the input. Single Precision Float Double Precision Float -inf -inf -finite -finite -denorm -finite -0 -0 +0 +0 +denorm +finite +finite +finite +inf +inf NaN NaN Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 28 3. Execution Environment 3.1 EU Overview The GEN instruction set is a general-purpose data-parallel instruction set optimized for graphics and media computations. Support for 3D graphics API (Application Programming Interface) Shader instructions is mostly native, meaning that GEN efficiently executes Shader programs. Depending on Shader program operation modes (for example, a Vertex Shader may be executed on a base of a vertex pair, while a Pixel Shader may be executed on a base of a 16-pixel group), translation from 3D graphics API Shader instruction streams into GEN native instructions may be required. In addition, there are many specific capabilities that accelerate media applications. The following feature list summarizes the GEN instruction set architecture:  SIMD (single instruction multiple data) instructions. The maximum number of data elements per instruction depends on the data type.  SIMD parallel arithmetic, vector arithmetic, logical, and SIMD control/branch instructions.  Instruction level variable-width SIMD execution.  Conditional SIMD execution via destination mask, predication, and execution mask.  Instruction compaction.  An instruction may executed in multiple cycles over a SIMD execution pipeline.  Most GEN instructions have three operands. Some instructions have additional implied source or destination operands. Some instructions have explicit dual destinations.  Region-based register addressing.  Direct or indirect (indexed) register addressing.  Scalar or vector immediate source operand.  Higher precision accumulator registers are architecturally visible.  Self-modifying code is not allowed (instruction streams, including instruction caches, are read-only). CoIssue/Dual Issue: The Gen7 generation of EU allows two instructions to be issued at the same time (sometimes referred to as “dual-issue” or more generally “co-issue”). The two instructions issued are always from different threads. The terms “FPU Pipe” and “EM Pipe” are the terms used when refering to the two simultaneous pipes. The Gen7 implementation dual-issue capability is limited to only the most popular instructions and source operand modes. Later generations of EU expand on this concept to allow more operations. Description: Opcodes: add, mov, mad, mul, cmp  Datatype: single precision floats.  Accessmode: o Align1:  No Scattering or Gathering data. This means data in source and destination registers are aligned and packed (data is contiguous in a register). //Example: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 29 // allowed, data is contiguous and source and destination regioning map one to one. mov (8) r10.0:f r11.0<8;8,1>:f // not allowed, data from source is strided and requires gathering to write to destination mov (8) r10.0:f r11.0<4;4,2>:f // not allowed, data from source is contiguous but not aligned with destination. Destination register requires scattering mov (8) r10.0<2>:w r11.0<8;8,1>:w //not allowed, data from source is contiguous but destination is not aligned to source mov (8) r10.1:f r11.0<4;4,1>:f // allowed. Source and destination have stride but are aligned mov (4) r10.1:f r11.1<4;4,1>:f  A single precision float scalar is allowed. o Align16  Addressmode: Direct Addressing  Register File: GRF/NULL. No access to Accumulator.  Condition modifiers supported only for cmp. 3.2 Primary Usage Models In describing the usage models of the GEN instruction set, the following sections forward reference terminology, syntax, and instructions described later in this specification. For clarity reasons, not all forward references are explained at the point of reference. See the Instruction Set Summarychapter for information about instruction fields and syntax. 3.2.1 AOS and SOA Data Structures With the Align1 and Align16 access modes, the GEN instruction set provides effective SIMD computation whether data is arranged in array of structures (AOS) form or in structure of arrays (SOA) form. The AOS and SOA data structures are illustrated by the examples in AOS and SOA Data Structures. The example shows two different ways of storing four vectors in four SIMD registers. For simplicity, the data vector and the SIMD register both have four data elements. The four data elements in a vector are denoted by X, Y, Z, and W just as for a vertex in 3D geometry. The AOS structure stores one vector in a register and the next vector in another register. The SOA structure stores one data element of each vector in a register and the next element of each vector in the next register and so on. The two structures can be related by a matrix transpose operation. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 30 AOS and SOA Data Structures GEN 3D and media applications take advantage of such broad architecture support and use both AOS and SOA data arrangements.  Vertices in 3D Geometry (Vertex Shader and Geometry Shader) are arranged in AOS form and use SIMD4x2 and SIMD4 modes, respectively, as detailed below.  Pixels in 3D Rasterization (Pixel Shader) are arranged in SOA form and use SIMD8 and SIMD16 modes as detailed below.  Pixels in media are primarily arranged in SOA form, and occasionally in AOS form with possibly mixed modes of operation that uses region-based addressing extensively. These are preferred methods; alternative arrangements may also be possible. Shared function resources provide data transpose capability to support both modes of operations: The sampler has a transpose for sample reads, the data port has a transpose for render cache writes, and the URB unit has a transpose for URB writes. The following 3D graphics API Shader instruction is used in the following sections to illustrate various operation modes: add dst.xyz src0.yxzw src1.zwxy This example is a SIMD instruction that takes two source operands src0 and src1, adds them, and stores the result to the destination operand dst. Each operand contains four floating-point data elements. The data type is determined by the instruction opcode. This instruction also uses source swizzles (.yxzw for src0 and .zwxy for src1) and a destination mask (.xyz). Please refer to the programming specifications of 3D graphics API Shader instructions for more details. A general register has 256 bits, which can store 8 floating point data elements. For 3D graphics, the mode of operation is (loosely) termed after the data structure as SIMDmxn, where m is the size of the vector and n is the number of concurrent program flows executed in SIMD. Execution with AOS data structures:  SIMD4 (short for SIMD4x1) indicates that a SIMD instruction operates on 4-element vectors storedin registers. There is one program flow. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 31  SIMD4x2 indicates that a SIMD instruction operates on a pair of 4-element vectors in registers. There are effectively two programs running side by side with one vector per program. Execution with SOA data structures, also referred to as “channel serial” execution, mostly uses:  SIMD8 (short for SIMD1x8) indicates a SIMD instruction based on the SOA data structure where one register contains one data element (the same one) for each of 8 vectors. Effectively, there are 8 concurrent program flows.  SIMD16 (short for SIMD1x16) indicates that a SIMD instruction operates on a pair of registers that contain one data element (the same one) for each of 16 vectors. SIMD16 has 16 concurrent program flows. 3.2.2 SIMD4 Mode of Operation With a register mapping of src0 to doublewords 0-3 of r2, src1 to doublewords 4-7 of r2 and dst to doublewords 0-3 of r3, the example 3D graphics API Shader instruction can be translated into the following GEN instruction: add (4) r3<4>.xyz:f r2<4>.yzwx:f r2.4<4>.zwxy:f {NoMask} Without diving too much into the syntax definition of a GEN instruction, it is clear that a GEN instruction also takes two source operands and one destination operands. The second term, (4), is the execution size that determines the number of data elements processed by the SIMD instruction. It is similar to the term SIMD Width used in the literature. Each operand is described by the register region parameters such as ‘<4>’ and data type (e.g. “:f”). These will be detailed in the SIMD8 Mode of Operation section. The instruction option field, {NoMask}, ensure that the execution occurs for the execution channels shown in the instruction, instead of, possibly, being masked out by the conditional masks of the thread (See Instruction Summary chapter for definition of MaskCtrl instruction field). The operation of this GEN instruction is illustrated in the following figure. In this example, both source operands share the same physical GRF register r2. The two are distinguished by the subregister number. The source swizzles control the routing of source data elements to the parallel adders corresponding to the destination data elements. The shaded areas in the destination register r3 are not modified. In particular, doublewords 4-7 are unchanged as the execution size is 4; doubleword 3 is unchanged due to the destination mask setting. In this mode of operation, there is only one program flow – any branch decision will be based on a scalar condition and apply to the whole vector of four elements. Option {NoMask} ensures that the instruction is not subject to the masks. In fact, most of the instructions in a thread should have {NoMask} set. Even though the execution only performs four parallel add operations, the GEN instruction still executes in 2 cycles (with no useful computation in the second cycle). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 32 A SIMD4 Example 3.2.3 SIMD4x2 Mode of Operation In this mode, two corresponding vectors from the two program flows fill a GEN register. With a register mapping of src0 to r2, src1 to r3 and dst to r4, the example 3D graphics API Shader instruction can be translated into the following GEN instruction: add (8) r4<4>.xyz:f r2<4>.yxzw:f r3<4>.zwxy:f This instruction is subject to the execution mask, which initiated from the dispatch mask. If both program flows are available (e.g. Vertex Shader executed with two active vertices), the dispatch mask is set to 0x00FF. The operation of this GEN instruction is illustrated in SIMD4x2 Mode of Operation (a). The source swizzles control the routing of source data elements to the parallel adders corresponding to the destination data elements. The shaded areas in the destination register r3 (doublewords 3 and 7) are unchanged due to the destination mask setting. If only one program flow is available (e.g. the same SIMD4x2 Vertex Shader with only one active vertex), the dispatch mask is set to 0x000F. The operation of the same instruction is shown in SIMD4x2 Mode of Operation (b). SIMD4x2 Examples with Different Emasks The two source operands only need to be 16-byte aligned, not have to be GRF register aligned. For example, the first source operand could be a 4-element vector (e.g. a constant) stored in doublewords 0-3 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 33 in r2, which is shared by the two program flows. The example 3D graphics API Shader instruction can then be translated into the following GEN instruction: add (8) r4<4>.xyz:f r2<0>.yzwx:f r3<4>.zwxy:f The only difference here is that the vertical stride of the first source is 0. The operation of this GEN instruction is illustrated in SIMD4x2 Mode of Operation. A SIMD4x2 Example with a Constant Vector Shared by Two Program Flows 3.2.4 SIMD16 Mode of Operation With 16 concurrent program flows, one element of a vector would take two GRF registers. In this mode, two corresponding vectors from the two program flows fill a GEN register. With the following register mappings, src0:r2-r9 (with 16 X data elements in r2-r3, Y in r4-5, Z in r6-7 and W in r8-9), src1: r10-r17, dst:r18-r25, the example 3D graphics API Shader instruction can be translated into the following three GEN instructions: add (16) r18<1>:f r4<8;8,1>:f r14<8;8,1>:f// dst.x = src0.y + src1.z add (16) r20<1>:f r6<8;8,1>:f r16<8;8,1>:f// dst.y = src0.z + src1.w add (16) r22<1>:f r8<8;8,1>:f r10<8;8,1>:f // dst.z = src0.w + src1.x The three GEN instructions correspond to the three enabled destination masks As there is no output for the W elements of dst, no instruction is needed for that element. The first instruction inputs the Y elements of src0 and the Z elements of src1 and outputs the X elements of dst. The operation of this instruction is shown in SIMD16 Mode of Operation. With more than one program flow, the above instructions are also subject to the execution mask. The 16- bit dispatch mask is partitioned into four groups with four bits each. For Pixel Shader generated by the Windower, each 4-bit group corresponds to a 2x2 pixel subspan. If a subspan is not valid for a Pixel Shader instance, the corresponding 4-bit group in the dispatch mask is not set. Therefore, the same Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 34 instructions can be used independent of the number of available subspans without creating bogus data in the subspans that are not valid. A SIMD16 Example Similar to SIMD4x2 mode, a constant may also be shared for the 16 program flows. For example, the first source operand could be a 4-element vector (e.g. a constant) stored in doublewords 0-3 in r2 (AOS format). The example 3D graphics API Shader instruction can then be translated into the following GEN instruction: add (16) r18<1>:f r2.1<0;1,0>:f r14<8;8,1>:f {Compr}// dst.x = src0.y + src1.z add (16) r20<1>:f r2.2<0;1,0>:f r16<8;8,1>:f {Compr}// dst.y = src0.z + src1.w add (16) r22<1>:f r2.3<0;1,0>:f r10<8;8,1>:f {Compr}// dst.z = src0.w + src1.x The register region of the first source operand represents a replicated scalar. The operation of the first GEN instruction is illustrated in SIMD16 Mode of Operation. Another SIMD16 Example with an AOS Shared Constant Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 35 3.2.5 SIMD8 Mode of Operation Each compressed instruction has two corresponding native instructions. Taking the example instruction shown in SIMD16 Mode of Operation, it is equivalent to the following two instructions. add (8) r18<1>:f r4<8;8,1>:f r14<8;8,1>:f // dst.x[7:0] = src0.y + src1.z add (8) r19<1>:f r5<8;8,1>:f r15<8;8,1>:f {SecHalf}// dst.x[15:8] = src0.y + src1.z Therefore, SIMD8 can be viewed as a special case for SIMD16. There are other reasons that SIMD8 instructions may be used. Within a program with 16 concurrent program flows, some time SIMD8 instruction must be used due to architecture restrictions. For example, the address register a0 only have 8 elements, if an indirect GRF addressing is used, SIMD16 instructions are not allowed. 3.3 Registers and Register Regions 3.3.1 Register Files GEN registers are grouped into different name spaces called register files. There are two register files, the General Register File and the Architecture Register File. A third encoding of some register file instruction fields indicates immediate operands within instructions rather than a register file.  General Register File (GRF): The GRF contains general-purpose read-write registers.  Architecture Register File (ARF): The ARF contains all architectural registers defined for specific purposes, including address registers (a#), accumulators (acc#), flags (f#), notification count (n#), instruction pointer (ip), null register (null), etc.  Immediate: Certain instructions can take immediate source operands. A distinct register file field encoding indicates an immediate operand. Each thread executed in an EU has its own thread context, a dedicated register space that is not shared between threads, whether executing on a common EU or on a different EU. In the rest of the chapters in this volume, register access is relative to a given thread. 3.3.2 GRF Registers Number of Registers: Various Default Value: None Normal Access: RW Elements: Various Element Size: Various Element Type: Various Access Granularity: Byte Write Mask Granularity: Byte Indexable? Yes Registers in the General Register File are the most commonly used read-write registers. During the execution of a thread, GRF registers are used to store the temporary data, and serve as the destination to Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 36 receive data from shared function units (and some times from a fixed function unit). They are also used to store the input (initialization) data when a thread is created. By allowing fixed function hardware to initialize some portion of GRF registers during thread dispatch time, GEN architecture can achieve better parallelism. A thread’s execution efficiency can also be improved as some data are already in the register to be executed upon. Besides these registers containing thread’s payload, the rest of GRF registers of a thread are not initialized. Summary of GRF Registers Register File Register Name Description General purpose read write registers General Register File (GRF) r# Each execution unit has a fixed size physical GRF register RAM. The GRF register RAM is shared by all threads on the EU. Each thread has a dedicated space of 128 register, r0 through r127. GRF registers can be accessed using region-based addressing at byte granularity (both read and write). A source operand must be contained within two adjacent registers. A destination operand must be contained within one register. GRF registers support direct addressing and register-indirect addressing. Register-indirect addressing uses the address registers (ARF registers a#) and an immediate address offset value. When accessing (read and/or write) outside the GRF register range allocated for a given thread either through direct or indirect addressing, the result is unpredictable. 3.3.3 ARF Registers 3.3.3.1 ARF Registers Overview Besides GRF and MRF registers that are directly indicated by unique register file coding, all other registers belong to the Architecture Register File (ARF). Encodings of architecture register types are based on the MSBs of the register number field, RegNum, in the instruction word. The RegNum field has 8 bits. The 4 MSBs, RegNum[7:4], represent the architecture register type. This is summarized in the following table. Summary of Architecture Registers Register Type (RegNum Register Register [7:4]) Name Count Description 0000b null 1 Null register 0001b a0.# 1 Address register 0010b acc# 2 Accumulator register 0011b f#.# 2 Flag register 0101b Reserved Reserved 0110b Reserved Reserved 0111b sr0.# 1 State register 1000b cr0.# 1 Control register 1001b n# 2 Notification Count register 1010b ip 1 Instruction Pointer register 1011b tdr 1 Thread Dependency register 1100b tm0 1 TimeStamp register 1101b Reserved Reserved Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 37 Register Type (RegNum Register Register [7:4]) Name Count Description 1110b Reserved Reserved The remaining register number field RegNum[3:0] is used to identify the register number of a given architecture register type. Therefore, the maximum number of registers for a given architecture register type is limited to 16. The subregister number field, SubRegNum, in the instruction word has 5 bits. It is used to address subregister regions for an architecture register supporting register subdivision. The SubRegNum field is in units of bytes. Therefore, the maximum number of bytes of an architecture register is limited to 32. Depending on the alignment restriction of a register type, only certain encodings of SubRegNum field apply for an architecture register. The detailed definitions are provided in the following sections. In general an ARF register can be dst (destination) or src0 (source 0, first source operand) for an instruction. Depending on the register and the instruction, other restrictions may apply. 3.3.3.2 Access Granularity ARF registers may be accessed with subregister granularity according to the descriptions below and following the same rule of region-based addressing for GRF. The machine code for register number and subregister number of ARF follows the same rule as for other register files with byte granularity. For an ARF as a source operand, the region-based address controls the source swizzle mux. The destination subregister number and destination horizontal stride can be used to generate the destination write mask at byte level. A special restriction on region-based addressing for ARF is that the register region cannot cross a register boundary. Subregister fields of an ARF register may not all be populated (indicated by the subregister being indicated as reserved). Writes to unpopulated subregisters are dropped; there are no side effect. Reads from unpopulated subregisters, if not specified, return unpredictable data. Some ARF registers are read-only. Writes to read-only ARF registers are dropped and there are no side effects. 3.3.3.3 Null Register Null Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 0000b Number of Registers: 1 Default Value: N/A Normal Access: N/A Elements: N/A Element Size: N/A Element Type: N/A Access Granularity: N/A Write Mask Granularity: N/A SecHalf Control? N/A Indexable? No Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 38 The null register is a special encoding for an operand that does not have a physical mapping. It is primarily used in instructions to indicate non-existent operands. Writing to the null register has no side effect. Reading from the null register returns an undefined result. The null register can be used where a source operand is absent. For example, for a single source operand instruction such as MOV or NOT, the second source operand src1 must be a null register. When the null register is used as the destination operand of an instruction, it indicates the computed results are not stored in any registers. However, implied writes to the accumulator register, if applicable, may still occur for the instruction. When the conditional modifier is present, updates to the selected flag register also occur. In this case, the register region fields of the ‘null’ operand are valid. Another example use is to use the null register as the posted destination of a send instruction for data write to indicate that no write completion acknowledgement is required. In this case, however, the register region fields are still valid. The null register can also be the first source operand for a send instruction indicating the absent of the implied move. See the send instruction for details. 3.3.3.4 Address Register Address Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 0001b Number of Registers: 1 Default Value: None Normal Access: RW Elements: 8 Element Size: 16 bits Element Type: UW or UD Access Granularity: Word Write Mask Granularity: Word SecHalf Control? N/A Indexable? No There are eight address subregisters forming an 8-element vector. Each address subregister contains 16 bits. Address subregisters can be used as regular source and destination operands, as the indexing addresses for register-indirect-addressed access of GRF registers, and also as the source of the message descriptor for the send instruction. Register and Subregister Numbers for Address Register RegNum[3:0] SubRegNum[4:0] 0000b = a0 When register a0 or subregisters in a0 are used as the address register for register-indirect addressing, the address subregisters must be accessed as unsigned word integers. Therefore, All other encodings the subregister number field must also be word-aligned. are reserved. 00000b = a0.0:uw 00010b = a0.1:uw 00100b = a0.2:uw 00110b = a0.3:uw 01000b = a0.4:uw Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 39 RegNum[3:0] SubRegNum[4:0] 01010b = a0.5:uw 01100b = a0.6:uw 01110b = a0.7:uw All other encodings are reserved. However, when register a0 or subregisters in a0 are explicit source and/or destination registers, other data types are allowed as long as the register region falls in the 128-bit range. Address Register Fields DWord Bits Description 7 31:16 Address subregister a0.15:uw. Follows the same format as a0.3. 15:0 Address subregister a0.14:uw. Follows the same format as a0.2. 6 31:16 Address subregister a0.13:uw. Follows the same format as a0.3. 15:0 Address subregister a0.12:uw. Follows the same format as a0.2. 5 31:16 Address subregister a0.11:uw. Follows the same format as a0.3. 15:0 Address subregister a0.10:uw. Follows the same format as a0.2. 4 31:16 Address subregister a0.9:uw. Follows the same format as a0.3. 15:0 Address subregister a0.8:uw. Follows the same format as a0.2. 3 31:16 Address subregister a0.7:uw. Follows the same format as a0.3. 15:0 Address subregister a0.6:uw. Follows the same format as a0.2. 2 31:16 Address subregister a0.5:uw. Follows the same format as a0.3. 15:0 Address subregister a0.4:uw. Follows the same format as a0.2. 1 31:16 Address subregister a0.3:uw. This field, with only the lower 12 bits populated, can be used as an unsigned integer for register-indirect register addressing. Format: U12 15:0 Address subregister a0.2:uw. This field, with only the lower 12 bits populated, can be used as an unsigned integer for register-indirect register addressing. Format: U12 0 31:16 Address subregister a0.1:uw. This field can be used for register-indirect register addressing or serve as message descriptor for a send instruction. When used for register-indirect register addressing, it is a 12-bit unsigned integer. For a send instruction, it provides the higher 16 bits of . Format: U12 or U16. 15:0 Address subregister a0.0:uw. This field can be used for register-indirect register addressing or serve as message descriptor for a send instruction. When used for register-indirect register addressing, it is a 12-bit unsigned integer. For a send instruction, it provides the lower 16 bits of . Format: U12 or U16. When used as a source or destination operand, the address subregisters can be accessed individually or as a group. In the following example, the first instruction moves 8 address subregisters to the first half of GRF register r1, the second instruction replicates a0.4:uw as an unsigned word to the second half of r1, the third instruction moves the first 4 words in r1 into the first 4 address subregisters, and the fourth instruction replicates r1.4 as a unsigned word to the next 4 address subregisters. mov (8) r1.0<1>:uw a0.0<8;8,1>:uw // r1.n = a0.n for n = 0 to 7 in words mov (8) r1.8<1>:uw a0.4<0;1,0>:uw // r1.m = a0.4 for m = 8 to 15 in words mov (4) a0.0<1>:uw Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 40 r1.0<4;4,1>:uw // a0.n = r1.n for n = 0 to 3 in words mov (4) a0.4<1>:uw r1.4<0;1,0>:uw // a0.m = r1.4 for m = 4 to 7 in words When used as the register-indirect addressing for GRF registers, the address subregisters can be accessed individually or as a group. When accessed as a group, the address subregisters must be group- aligned. For example, when two address subregisters are used for register indirect addressing, they must be aligned to even address subregisters. In the following example, the first instruction is legal. However, the second one is not. As ExecSize = 8 and the width of src0 is 4, two address subregisters are used as row indices, each pointing to 4 data elements spaced by HorzStride = 1 dword. For the first instruction, the two address subregisters are a0.2:uw and a0.3:uw. The two align to a DWord group in the address register. However, the two address subregisters for the second instruction are a0.3:uw and a0.4:uw. They are not DWord-aligned in the address register and therefore violate the above mentioned alignment rule. mov (8) r1.0<1>:d r[a0.2]<4,1>:d // a0.2 and a0.3 are used for src1 mov (8) r1.0<1>:d r[a0.3]<4,1>:d // ILLEGAL use of register indirect Implementation restriction: GEN ISA supports per channel indexing for a source operand. As there are only 8 sub-fields in the address register (to save hardware cost), the execution size of an instruction using per-channel indexing is limited to 8. Software may reload the address register and use compression control SecHalf to complete a 16-channel computation. Implementation restriction: When used as the source operand for the send instruction, only the first dword subregister of a0 register is allowed (i.e. a0.0:ud, which can be viewed as the combination of a0.0:uw and a0.1:uw). In addition, it must be of UD type and in the following form = a0.0<0;1,0>:ud. Implementation restriction: Elements a0.0 and a0.1 have 16 bits each, but the rest of the elements (a0.2:uw through a0.7:uw) only have 12 bits populated each. 12-bit precision supports full indirect- addressing capability for the largest GRF register range. Software must observe the asymmetry of the implementation. When a0.0:uw and a0.1:uw are the source or destination, full 16-bit precision is preserved. However, when a0.2:uw to a0.7:uw are the destination, the high 4 bits for each element are dropped; when they are the source, hardware inserts zero to the high 4 bits for each element. Performance Note: There is only one scoreboard for the whole address register. When a write to some subregisters is in flight, hardware stalls any instruction writing to other subregisters. Software may use the destination dependency control {NoDDChk, NoDDClr} to improve performance in this case. Similarly, when a write to some subregisters is in flight, hardware stalls any instruction sourcing other subregisters until the write retires. 3.3.3.5 Accumulator Registers Accumulator Registers Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 0010b Number of Registers: 2 Default Value: None Normal Access: RW Accumulator registers can be accessed either as explicit or implied source and/or destination registers. To a programmer, each accumulator register may contain either 8 DWords or 16 Words of data elements. However, as described in the Implementation Precision Restriction notes below, each data element may have higher precision with added guard bits not indicated by the numeric data type. Accumulator capabilities vary by data type, not just data size, as described in the Accumulator Channel Precision table below. For example, D and F are both 32-bit data types, but differ in accumulator support. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 41 See the Accumulator Restrictions section for information about additional general accumulator restrictions and also accumulator restrictions for specific instructions. There are two accumulator registers, acc0 and acc1. Register and Subregister Numbers for Accumulator Registers RegNum[3:0] SubRegNum[4:0] 0000b = acc0 Reserved: MBZ. 0001b = acc1 All other encodings are reserved.  Accumulators are updated implicitly only if the AccWrCtrl bit is set in the instruction. The Accumulator Disable bit in control register cr0.0 allows software to disable the use of AccWrCtrl for implicit accumulator updates. The write enable in word granularity for the instruction is used to update the accumulator. Data in disabled channels is not updated.  When an accumulator register is an implicit source or destination operand, hardware always uses acc0 by default and also uses acc1 if the execution size exceeds the number of elements in acc0. When implicit access to acc1 is required, QtrCtrl is used. Note that QtrCtrl can be used only if acc1 is accessible for a given data type. If acc1 is not accessible for a given data type, QtrCtrl defaults to acc0. acc0 and acc1 are supported for single-precision Float (F) only. Use QtrCtrl of Q2 or Q4 to access acc1. Examples: // Updates acc0 and acc1 because it is SIMD16: add (16) r10:f r11:f r12:f {AccWrEn} // Updates acc0 because it is SIMD8: add (8) r10:f r11:f r12:f {AccWrEn} // Updates acc1. Implicit access to acc1 using QtrCtrl: add (8) r10:f r11:f r12:f {AccWrEn, Q2} // Updates acc1 for Half Floats using QtrCtrl: add (16) r10:hf r11:hf r12:hf {AccWrEn, H2}  It is illegal to specify different accumulator registers for source and destination operands in an instruction (e.g. “add (8) acc1:f acc0:f”). The result of such an instruction is unpredictable.  Some processor generations or steppings limit SIMD16 Float operations, as follows:  SIMD16 execution on Floats is not allowed when an accumulator is an explicit source or destination operand.  Accumulator registers may be accessed explicitly as src0 operands only.  Swizzling is not allowed when an accumulator is used as an implicit source or an explicit source in an instruction.  For any DWord operation, including DWord multiply, accumulator can store up to 8 channels of data, with only acc0 supported.  When an accumulator register is an explicit destination, it follows the rules of a destination register. If an accumulator is an explicit source operand, its register region must match that of the destination register with the exception described below. Implementation Precision Restriction: As there are only 64 bits per channel in DWord mode (D and UD), it is sufficient to store the multiplication result of two DWord operands as long as the post source Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 42 modified sources are still within 32 bits. If any one source is type UD and is negated, the negated result becomes 33 bits. The DWord multiplication result is then 65 bits, bigger than the storage capacity of accumulators. Consequently, the results are unpredictable. Implementation Precision Restriction: As there are only 33 bits per channel in Word mode (W and UW), it is sufficient to store the multiplication result of two Word operands with and without source modifier as the result is up to 33 bits. Integers are stored in accumulator in 2's complement form with bit 32 as the sign bit. As there is no guard bit left, the accumulator can only be sourced once before running into a risk of overflowing. When overflow occurs, only modular addition can generate a correct result. But in this case, conditional flags may be incorrect. When saturation is used, the output is unpredictable. This is also true for other operations that may result in more than 33 bits of data. For example, adding UD (FFFFFFFFh) with D (FFFFFFFFh) results in 1FFFFFFFEh. The sign bit is now at bit 34 and is lost when stored in the accumulator. When it is read out later from the accumulator, it becomes a negative number as bit 32 now becomes the sign bit. Accumulator Channel Precision Number Data Accumulator of Bits Per Type Number Channels Channel Description DF acc0 4 64 When accumulator is used for Double Float, it has the exact same precision as any GRF register. F acc0/acc1 8 32 When accumulator is used for Float, it has the exact same precision as any GRF register. D acc0 8 33/64 When the internal execution data type is doubleword integer, each (UD) accumulator register contains 8 channels of (extended) doubleword integer values. The data are always stored in accumulator in 2's complement form with 64 bits total regardless of the source data type. This is sufficient to construct the 64-bit D or UD multiplication results using an instruction macro sequence consisting of mul, mach, and shr (or mov). W acc0 16 33 When the internal execution data type is word integer, each accumulator (UW) register contains 16 channels of (extended) word integer values. The data are always stored in accumulator in 2's complement form with 33 bits total. This supports single instruction multiplication of two word sources in W and/or UW format. B N/A N/A N/A Not supported data type. (UB) 3.3.3.6 Flag Register Flag Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 0011b Number of Registers: 2 Default Value: None Normal Access: RW Elements: 2 Element Size: 32 bits Element Type: UD Access Granularity: Word Write Mask Granularity: Word Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 43 Attribute Value SecHalf Control? Yes Indexable? No There are two flag registers, f0 and f1. Each flag register contains two 16-bit subregisters. Each flag bit corresponds to a data channel. Predication uses flag values to enable or disable channels. Conditional modifiers assign flag values. If an instruction uses both predication and conditional modifiers, both features use the same flag register or subregisters. Flags can be split to halfs, quarters, or eighths using the QtrCtrl and NibCtrl instruction fields. Those fields affect the selection of flags for predication and conditional modifiers, but do not affect reading or writing flags as explicit instruction operands. The values held in the individual bits of a flag register are the result of the most recent instruction with a conditional modifier and specifying that flag register. For example: add.nz.f0.0 ... Updates flag subregister f0.0 with the per-channel results of the not zero condition. The flag register has per-bit write enables. When being updated as the secondary destination associated with a conditional modifier, only the bits corresponding to the enabled channels in EMask are updated. Other bits in the flag subregister are unchanged. Flag registers and subregisters can also be explicit source or destination operands. The sel instruction does not update flags. Note: When branching instructions are predicated, branching is evaluated on all channels enabled at dispatch. This means, the appropriate number of flag register bits must be initialized or used in predication depending on the execution mask (EMask). Uninitalized flags may result in undesired branching. For example, if using DMask as EMask and if all 32 channels of DMask are enabled, a SIMD8 kernel must initialize unused flag bits so that predication on branching is evaluated correctly. Register and Subregister Numbers for Flag Register RegNum[3:0] SubRegNum[4:0] 0000b = f0:ud 00000b = fn.0:uw 0001b = f1:ud 00010b = fn.1:uw Other encodings are reserved. Other encodings are reserved. Reference an entire flag register as f0:ud or f1:ud. Reference the flag subregisters as f0.0:uw, f0.1:uw, f1.0:uw, and f1.1:uw. 3.3.3.7 State Register State Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 0111b Number of Registers: 1 Default Value: Provided by the Dispatcher Normal Access: RW Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 44 Attribute Value Elements: 4 Element Size: 32 bits Element Type: UD Access Granularity: Byte Write Mask Granularity: N/A SecHalf Control? No Indexable? No Register and Subregister Numbers for State Register RegNum[3:0] SubRegNum[4:0] 0000b = sr0 Valid encoding range: All other encodings are reserved. 00000b – 01100b All other encodings are reserved. State Register Fields DWord Bits Description 31:28 Reserved. MBZ. 0 27:24 FFID (Fixed Function Identifier). Specifies which fixed function unit generates the current thread. (sr0.0:ud) This field is set at thread dispatch and is forwarded on the message bus for all out-going messages from this thread. 23 Priority Class. This field, when set, indicates the thread belongs to the high priority class, which has higher scheduling priority over any thread with this field cleared. The priority field below determines the relative priority within the same priority class. This field is initialized by the thread dispatcher at thread dispatch time and stays unchanged throughout the life span of the thread. This field is forwarded on the message bus to the message bus arbiter for all out-going messages. It serves as a priority hint for the target shared function. See the Shared Function chapters for whether and how a shared function uses this priority hint. 0 = Low priority class. 1 = High priority class. 22:19 Reserved. MBZ. 18:16 Priority. This field is the relative aging priority of the thread. This field indicates the ‘age’ of this thread relative to other threads within the EU. No two threads in the same EU can have the same priority number (independent of the priority class value). Within the same priority class, an older thread (with a larger priority number) has higher schedule priority over a younger thread. This field is set to zero at a thread’s dispatch. During a thread’s run time, this field may or may not be incremented when a new thread is dispatched to the same EU. It is only incremented when another thread’s priority number is incremented and reaches the same value. For example, if currently there is a thread with priority 0 on an EU, then dispatching a new thread to that EU causes the old thread’s priority number to increment to 1. However, if the active thread (assuming for simplicity that there is only one) on an EU has a priority number 1 (or 2 or 3), then dispatching a new thread to this EU does not change the old thread’s priority number. As threads on an EU may terminate in arbitrary order, the exact number for a thread depends on the dynamic execution of threads. 15:8 : [15:13] Reserved. MBZ. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 45 DWord Bits Description [12] HSID. HalfSlice Identifier for the EU. [11:8] EUID[3:0]. Execution Unit Identifier. The MSB of this field is the RowID. 7:3 Reserved. MBZ. 2:0 TID (The thread identifier). Specifies the thread slot that the current thread is assigned to. This field is set at thread dispatch. 31:24 FFTID (Fixed Function Thread ID). There is no connection between this thread ID, assigned in fixed 1 functions, and the TID assigned in the EUs. (sr0.1:ud) 23:0 Reserved. MBZ. 31:23 1 (sr0.1:ud) 31:0 2 Dispatch Mask (DMask). This 32-bit field specifies which channels are active at Dispatch time. This field is used by hardware to initialize the mask register. (sr0.2:ud) Format: U32 31:0 3 Vector Mask (VMask). This 32-bit field contains, for each 4-bit group, the OR of the corresponding 4-bit group in the dispatch mask. This field is used by hardware to initialize the mask register. (sr0.3:ud) Format: U32 3.3.3.8 Control Register Control Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 1000b Number of Registers: 1 Default Value: Provided by the Dispatcher Normal Access: RW Elements: 4 Element Size: 32 bits Element Type: UD Access Granularity: DWord Write Mask Granularity: DWord SecHalf Control? No Indexable? No The Control register is a read-write register. It contains four 32-bit subregisters that can be accessed individually. Subregister cr0.0:ud contains normal operation control fields such as the floating-point mode and the accumulator disable. It also contains the master exception status/control field that allows software to switch back to the application thread from the System Routine. Subregister cr0.1:ud contains the mask and status/control fields for all exceptions. The exception fields are arranged in significance-decreasing order from MSB to LSB. This arrangement allows the System Routine to use the lzd instruction to find the high priority exceptions and handle them first. As each exception is mapped to a single bit, another exception priority order may be implemented by software. The System Routine may choose to handle one exception at a time, by handling the exception detected Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 46 by an lzdinstruction and returning to the application thread. Or it may choose to handle all the concurrent exceptions, by looping through the exception fields until all outstanding exceptions are handled before returning back to the application thread. Exception enable bits (bits 15:0 in cr0.1:ud) control whether an exception causes hardware to jump to the System Routine or not. Exception status and control bits (bits 31:16 in cr0.1:ud) indicate which exceptions have occurred, and are used by the system routine to clear the exception. Even if a given exception is disabled, the corresponding exception status and control bit still reflects its status, whether an exception event has occurred or not. cr0.2:ud contains the Application IP (AIP) indicating the current thread IP when an exception occurs. cr0.3:ud is reserved. Values written to this subregister are dropped; the result of reading from this subregister is unpredictable. Fields in Control registers also reference a virtual register called System IP (SIP). SIP is the virtual register holding the global System IP, which is the initial instruction pointer for the System Routine. There is only one SIP for the whole system. It is virtual only from a thread’s point of view, as it is not visible (i.e. not readable and not writeable) to the thread software executed on a GEN EU. It can only be accessed indirectly by the hardware to respond to exception events. Upon an exception, hardware performs some bookkeeping (e.g. saving the current IP into AIP) and then jumps to SIP. Upon finishing exception handling, the System Routine may return back to the application by clearing the Master Exception Status and Control field in cr0, which causes the hardware to load AIP to IP register. See the STATE_SIP command for how to set SIP. Register and Subregister Numbers for Control Register RegNum[3:0] SubRegNum[4:0] 0000b = cr0 00000b = cr0.0:ud. It contains general thread control fields. All other encodings are reserved. 00100b = cr0.1:ud. It contains exception status and control. 01000b = cr0.2:ud. It contains AIP. All other encodings are reserved. Control Register Fields DWord Bits Description 0 31 Master Exception State and Control. This bit is the master state and control for all exceptions. Reading a 0 indicates that the thread is in normal operation state and a 1 means the thread is in exception handle state. Upon an exception event, hardware sets this bit to 1 and switches to SIP. Writing 1 to this bit has no effect. Writing 0 to this bit also has no effect if the previous value is 0. In both cases, the bit keeps the previous value. If the previous value of this bit is 1, software writing a 0 causes the thread to return to AIP. This transition is automatic – software does not have to move AIP to IP. The value of this bit then stays as 0. This bit is initialized to 0. 0 = The thread is in normal state. 1 = The thread is in exception state. 30:16 Reserved. MBZ. 15 Breakpoint Suppress. This bit specifies whether breakpoint exception is suppressed or not. This bit is normally set by software and cleared by hardware. If Master Exception Status and Control bit is 1, this bit is ignored by hardware. If Master Exception Status and Control bit is 0 (i.e. not in System Routine) and Breakpoint is enabled: If this bit is set, breakpoint is temporally ignored (suppressed); Upon a breakpoint condition, the instruction is executed and this bit is automatically reset by hardware. This bit is provided to prevent infinite loops of jumping to the System Routine on a breakpoint Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 47 DWord Bits Description condition. The System Routine must set this bit (and also clear the corresponding status and control bit) before returning to the application thread. This bit has no effect when Breakpoint Enable bits are cleared. This bit is initialized to 0. 0 = Breakpoint exception is not suppressed. 1 = Breakpoint exception is suppressed. 14:10 Reserved. MBZ. 7 Reserved. 6 Double Precision Denorm Mode. This bit determines how denormal numbers are handled for the DF (Double Float) type. It is initialized by Thread Dispatch. 0 = Flush denorms to zero when reading source operands and flush denorm calculation results to zero. Denorm flushing preserves sign. 1 = Allow denorm source values and denorm results. 5:4 Rounding Mode. This field specifies the FPU rounding mode. It is initialized by Thread Dispatch. 00b = Round to Nearest or Even (RTNE) 01b = Round Up, toward +inf (RU) 10b = Round Down, toward -inf (RD) 11b = Round Toward Zero (RTZ) 3 Vector Mask Enable (VME). This bit indicates DMask or Vmask should be used by EU for execution. This bit is set by the Thread Dispatch. 0: Use Dispatch Mask (DMASK) 1: Use Vector Mask (VMASK) 2 Single Program Flow (SPF). Specifies whether the thread has a single program flow (SIMDnxm with m = 1) or multiple program flows (SIMDnxm with m > 1). This bit affects the operation of all branch instructions. In Single Program Flow mode, all execution channels branch and/or loop identically. This bit is initialized by the Thread Dispatch. 0: Multiple Program Flows 1: Single Program Flow Programming Restrictions: Only H1/Q1/N1 are allowed in SPF mode. Power Optimization: If an entire shader does not do SIMD branching, the driver can set the SPF bit to 1 to save power in HW. 1 Accumulator Disable. This bit controls the update of the accumulator by the instruction field AccWrCtrl. If this bit is cleared, the accumulator is updated for all instructions with AccWrCtrl enabled. If set, the accumulator is disabled for all update operations, maintaining its value prior to being disabled. Setting this bit has no effect if the accumulator is the explicit destination operand for an instruction. This bit is initialized to 0. 0: Enable accumulator update. 1: Disable accumulator update. Usage Notes: This control bit is primarily designed for the System Routine. That routine is not expected to use the accumulator,though it may need to use instructions that implicitly update the accumulator. To use Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 48 DWord Bits Description such instructions in the System Routine, but still preserve the accumulator contents on returning to the application kernel, the System Routine would either (a) save and restore the accumulator, or (b) prevent the accumulator from being unintentionally modified. This control bit has been added for the latter method. Software has the option to limit the setting of this control bit to strictly within the System Routine. If, by convention, this bit is clear within application kernels, the System Routine can simply set the bit upon entry and clear it before returning control to the application kernel. This usage model would not necessarily require cr0.0 to be saved/ restored in the System Routine. However, if by convention application kernels are permitted to set this bit, then the System Routine is required to preserve the content of this bit. 0 Single Precision Floating Point Mode (FP Mode). This bit specifies whether the current single- precision floating-point operation mode is IEEE mode (IEEE Standard 754) or the ALT (alternative mode). This bit does not affect the floating-point mode used for other floating-point data types. This bit is also forwarded on the message sideband for all out-going messages, for example, to control the floating-point mode of the Sampler. Software may modify this bit to dynamically switch between the two floating-point modes. This bit is initialized by Thread Dispatch. 0 = IEEE floating-point mode for the F (Float) type. 1 = ALT (alternative) floating-point mode for the F (Float) type. 30 External Halt Exception Status and Control. This bit indicates the External Halt exception. It is set by EU hardware on receiving the broadcast External Halt signal. The System Routine should reset this bit before returning to an application routine to avoid infinite loops. This bit may be set or cleared by software. This bit is initialized to 0. 29 Software Exception Control. This bit is the control bit for software exceptions. Setting this bit to 1 in an application routine causes an exception. Clearing this bit in an application routine has no effect. Upon entering the system routine, the hardware maintains this bit as 1 to signify a software exception. The System Routine should reset this bit before returning to an application routine. This bit may be set or cleared by software. This bit is initialized to 0. 28 Illegal Opcode Exception Status. This bit, when set, indicates an illegal opcode exception. The exception handler routine normally does not return back to the application thread upon an illegal opcode exception. Leaving this bit set has no effect on hardware; if system software adversely returns to an application routine leaving this bit set, it doesn’t cause any exception. This bit should not be set by software or left set by the system routine to avoid confusion. This bit is initialized to 0. 27 Stack Overflow Exception Status. This bit when set, indicates a stack overflow exception. The exception handler routine normally does not return back to the application thread upon a stack overflow exception. Leaving this bit set has no effect on hardware; if system software adversely returns to an application routine leaving this bit set, it doesn’t cause any exception. This bit should not be set by software or left set by the system routine to avoid confusion. This bit is initialized to 0. 26:24 Reserved 23:16 Reserved. MBZ. 15 Breakpoint Enable. Specifies whether the breakpoint exception is enabled or not. This bit is initialized by the Thread Dispatcher. Format = ENABLED: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 49 DWord Bits Description 0: Disabled 1: Enabled 13 Software Exception Enable. This bit enables or disables the software exception. Enabling or disabling this bit may allow host software to turn on/off certain features (such as profiling) without changing the kernel program. This bit is initialized by the Thread Dispatcher. Format = ENABLED: 0: Disabled 1: Enabled 12 Illegal Opcode Exception Enable. This bit specifies whether the illegal opcode exception is enabled or not. The Illegal opcode exception includes illegal opcodes and undefined opcodes, caused by bad programs or run-time data corruption. This bit is initialized by the Thread Dispatcher. Software should normally assign this bit in the interface descriptor. Even though this mechanism is provided to disable the illegal opcode exception, it should be used with extreme caution. Format = ENABLED: 0: Disabled 1: Enabled 11 Stack Overflow Exception Enable. This bit specifies whether the stack overflow exception is enabled or not. The stack overflow exception includes an overflow or an underflow in the stack space allocated for the thread. This bit is initialized by the Thread Dispatcher. Software should normally assign this bit in the interface descriptor. Format = ENABLED: 0: Disabled 1: Enabled 10:0 Reserved. MBZ. 31:3 2 Application IP (AIP). This is the register storing the instruction pointer before an exception is handled. Upon an exception, hardware automatically saves the current IP into the AIP register, and (cr0.2:ud) then sets the Master Exception State and Control field to 1, which forces a switch to the System IP (SIP). The AIP register may contain either the pointer to the instruction that causes the exception or the one after (such as masked stack overflow/underflow exceptions). This is shown in the following table, where IP is the instruction that generated the exception. Exception Type AIP Value Breakpoint IP External Halt N/A (1) Software Exception IP + 1 Illegal Opcode IP (1) External Halt exception is asynchronous and not associated with an instruction. When the System Routine changes the Master Exception State and Control field from 1 to 0, hardware restores IP from this register. This field is writable allowing the returning IP to be altered after an exception is handled. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 50 DWord Bits Description 2:0 Reserved. MBZ. Implementation Restriction on Register Access:When the control register is used as an explicit source and/or destination, hardware does not ensure execution pipeline coherency. Software must set the thread control field to ‘switch’ for an instruction that uses control register as an explicit operand. This is important as the control register is an implicit source for most instructions. For example, fields like FPMode and Accumulator Disable control the arithmetic and/or logic instructions. Therefore, if the instruction updating the control register doesn’t set ‘switch’, subsequent instructions may have undefined results. 3.3.3.9 Notification Registers Notification Registers Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 1001b Number of Registers: 3 Default Value: No Normal Access: RO (RW – Context save/restore only) Elements: 3 Element Size: 32 bits Element Type: UD Access Granularity: DWord Write Mask Granularity: DWord SecHalf Control? No Indexable? No There are three notification registers (n0.0:ud, n0.1:ud, and n0.2:ud) used by the wait instruction. These registers are read-only, except under context restore, and can be accessed in 32-bit granularity. Write access to this register is allowed only when context is restored. It should be noted that in the extreme case, it is possible to have more notifications to a thread than the maximum allowed number of concurrent threads in the system. Therefore, the range of the thread-to- thread notification count in n0, is larger than the maximum number of threads computed by EUID * TID. There is only one bit for the host-to-thread notification count in n1. When directly accessed, this register is read-only. If the value is non zero, the only way to alter the value is to use the wait instruction to decrement the value until zero is reached. A wait instruction on a zero notification subregister causes the thread to stall, waiting for a notification signal from outside targeting the same subregister. See the wait instruction for details. Implementation Restriction: The notification registers are initialized to 0 after hardware/software reset. However, these registers are not reset at thread dispatch time. Register and Subregister Numbers for Notification Registers RegNum[3:0] SubRegNum[4:0] 0000b = n0 00000b = n0.0:ud All other encodings are reserved. 00100b = n0.1:ud 01000b = n0.2:ud All other encodings are reserved. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 51 Notification Register 0 Fields DWord Bits Description 0 31:16 Reserved. MBZ. 15:0 Thread to Thread Notification Count. This register is used by the WAIT instruction for thread-to- thread synchronization. The value read from this register specifies the outstanding notifications received from other threads. It can be changed indirectly by using the WAIT instruction. See the WAIT instruction for details. Format: U16 Notification Register 1 Fields DWord Bits Description 0 31:1 Reserved. MBZ. Notification Register 2 Fields DWord Bits Description 0 31:16 Reserved. MBZ. 15:0 Thread to Thread Notification Count. This register is used by the WAIT instruction for thread-to- thread synchronization. The value read from this register specifies the outstanding notifications received from other threads. It can be changed indirectly by using the WAIT instruction. See the WAIT instruction for details. Format: U16 Format of the Notification Register Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 52 3.3.3.10 IP Register IP Register Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 1010b Number of Registers: 1 Default Value: Provided by the Dispatcher Normal Access: RW Elements: 1 Element Size: 32 bits Element Type: UD Access Granularity: DWord Write Mask Granularity: DWord SecHalf Control? No Indexable? No The ip register can be accessed as a 32-bit quantity. It is a read-write register, containing the current instruction pointer, which is relative to the Generate State Base Address. Reading this register returns the instruction pointer of the current instruction. The 3 LSBs are always read as zero. Writing this register causes program flow to jump to the new address. When it is written, the 3 LSBs are dropped by hardware. Register and Subregister Numbers for IP Register RegNum[3:0] SubRegNum[4:0] 0000b = ip 00000b = ip:ud All other encodings are reserved. All other encodings are reserved. IP Register Fields DWord Bits Subfield Description 0 31:3 Ip. Specifies the current instruction pointer. This pointer is relative to the General State Base Address. 2:0 Reserved. MBZ. 3.3.3.11 TDR Registers TDR Registers Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 1011b Number of Registers: 8 Default Value: No Normal Access: RO/CW Elements: 8 Element Size: 16 bits Element Type: UW Access Granularity: Word Write Mask Granularity: Word SecHalf Control? No Indexable? No Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 53 There are 8 thread dependency registers (tdr0.0:uw to tdr0.7:uw) used by HW for the sendc instruction. These registers are read-only and can be accessed in 16-bit granularity. When accessed explicitly, each thread dependency register has FFTID in the lower 8 bits, bits 8 to 14 are forced to zero by HW. Bit 15 is the valid bit, which indicate whether the current thread has a dependency on the dependency thread stored in this thread dependency register. The thread dependency registers are read only, the valids can only be set with a thread dispatch, and are reset by broadcasting end of thread messages after a thread retired. The FFTID’s can only be changed with a therad dispatch. Any write into any of the TDR registers will clear the valid bit for the particular TDR if the write enable is true, the FFTID portion is strictly read only. Register and Subregister Numbers for TDR Registers RegNum[3:0] SubRegNum[4:0] 1011b = tdr0 00000b = tdr0.0:uw All other encodings are reserved. 00010b = tdr0.1:uw 00100b = tdr0.2:uw 00110b = tdr0.3:uw 01000b = tdr0.4:uw 01010b = tdr0.5:uw 01100b = tdr0.6:uw 01110b = tdr0.7:uw All other encodings are reserved. TDR Registers Fields DWord Bits Description 3 31 Valid7. This field indicates whether the thread specified by FFTID7 is still in-flight. 30:24 Reserved. MBZ 23:16 FFTID7. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 15 Valid6. This field indicates whether the thread specified by FFTID6 is still in-flight. 14:8 Reserved. MBZ 7:0 FFTID6. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 2 31 Valid5. This field indicates whether the thread specified by FFTID5 is still in-flight. 30:24 Reserved. MBZ 23:16 FFTID5. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 15 Valid4. This field indicates whether the thread specified by FFTID4 is still in-flight. 14:8 Reserved. MBZ 7:0 FFTID4. This field is the FFTID of the third thread that the current thread depends on. It can be Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 54 DWord Bits Description changed by the end of thread broadcasting messages. Format: U8 1 31 Valid3. This field indicates whether the thread specified by FFTID3 is still in-flight. 30:24 Reserved. MBZ 23:16 FFTID3. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 15 Valid2. This field indicates whether the thread specified by FFTID2 is still in-flight. 14:8 Reserved. MBZ 7:0 FFTID2. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 0 31 Valid1. This field indicates whether the thread specified by FFTID1 is still in-flight. 30:24 Reserved. MBZ 23:16 FFTID1. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 15 Valid0. This field indicates whether the thread specified by FFTID0 is still in-flight. 14:8 Reserved. MBZ 7:0 FFTID0. This field is the FFTID of the third thread that the current thread depends on. It can be changed by the end of thread broadcasting messages. Format: U8 3.3.3.12 Performance Registers Performance Registers Summary Attribute Value ARF Register Type Encoding (RegNum[7:4]): 1100b Number of Registers: 1 Default Value: 0h Normal Access: RO Elements: 2 Element Size: 32 bits Element Type: UD Access Granularity: Byte Write Mask Granularity: N/A SecHalf Control? No Indexable? No Starting with, a block of ARF register space is allocated for per-thread performance information. Currently only a timestamp register is defined within this space, although it is anticipated that future performance- related information would be located here also. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 55 Register and Subregister Numbers for Performance Registers RegNum[3:0] SubRegNum[4:0] 1100b = timestamp Valid encoding range: All other encodings are reserved. 00000b – 00111b (in units of bytes) All other encodings are reserved. Timestamp Register This generation defines a new low latency timestamp source, “TM”, available as part of a thread's Architectural Register File (ARF). This is a is free running counter, 64b in size, and exposed to the ISA as individual 32b high ‘TmHigh’ and low ‘TmLow’ unsigned integer source operands. As part of the EU's register space, access to the timestamp has a low and deterministic latency and therefore can be used for intra-kernel high resolution performance profiling. The TM counter is free running based on the EU’s clock and continues to increment across all time. Given a base EU clock frequency of 1.25 GHz and the counter’s 64b size, rollover of the lower 32b occurs approximately every 3.3 seconds, with the upper 32b value rollover measured as ~450 years. The TM count continues to increment during a thread's active/standby state transitions as well as context switches. It is read-only and not pre- or resettable under any software control, either kernel or driver, other than a full gfx reset. The 64b TM value is expected to be identical across all EUs of the system unless DOP clock gating is enabled. The TM features provides a 1-bit indicator ‘TmEvent’ which identifies the occurrence of a time-impacting event such as context switch or frequency change since the last time any portion of the Timestamp register value was read by that thread. Software that uses the Timestamp capability should check this bit to identify when a relative time calculation may be suspect. To properly use this additional information, the instrumentation code should operate on the Timestamp register value as a whole (i.e. as an 8 dword register) so that the 64b time and this 1b value are captured simultaneously, as opposed to 32b portions, to eliminate a the chance of missing a TmEvent that might occur between accesses to 32b portions of this register. Note: The Timestamp register is saved as part of thread state on context-save, but only ‘TmEvent’ is restored (and technically always restored to ‘1’ as a context switch had occurred). Timestamp Register Fields DWord Bits Description 7:3 31:0 Undefined. 2 31:29 Undefined. 0 TmEvent. Indicates a discontinuous time-impacting event (e.g. context switch, frequency change) occurred since any portion of the Timestamp register was last read, thus making any relative duration calculation based on this counter suspect. This bit is reset at the time a new thread is loaded, and on each read of any portion of the ‘Timestamp’ register. 1 31:0 TmHigh. The upper 32b of the 64b timestamp value sourced from Cr clock. Read-only. Format: U32 0 31:0 TmLow. The lower 32b of the 64b timestamp value sourced from Cr clock. Read-only. Format: U32 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 56 3.3.4 Immediate Two forms of immediate are provided as a source operand: scalar and vector. The immediate field in a GEN instruction has 32 bits. For a word or an unsigned word immediate data, software must replicate the same 16-bit immediate value to both the lower word and the high word of the 32-bit immediate field in a GEN instruction. For a scalar immediate, it can be of any of the specified numeric data types from a word to a dword. Byte and unsigned byte are not supported as the smallest internal type of the execution pipeline is word. These two numeric types are reserved for future extensions. The immediate form of vector allows a constant vector to be in-lined in the instruction stream. Both integer and float immediate vectors are supported. An immediate integer vector is denoted by type v or uv as imm32:v or imm32:uv, where the 32-bit immediate field is partitioned into 8 4-bit subfields. Refer to the Numeric DataType Section for description of the packing of vector integers to a dword. An immediate float vector is denoted by type vf as imm32:vf, where the 32-bit immediate field is partitioned into 4 8-bit subfields. Refer to the Numeric DataType Section for the description of the packing of vector floats to a dword. Restriction: When an immediate vector is used in an instruction, the destination must be 128-bit aligned with destination horizontal stride equivalent to a word for an immediate integer vector (v) and equivalent to a dword for an immediate float vector (vf). 3.3.5 Region Parameters Unlike conventional SIMD architectures where an N-bit wide SIMD instruction can only operate on N-bit aligned SIMD data registers, a region-based register addressing scheme is employed in GEN architecture. The region-based register addressing capability significantly improves the SIMD computation efficiency by providing per-instruction-based multiple data gathering from register file. This avoids instruction overhead to perform data pack, unpack, and shuffling, which has been observed on other SIMD architectures. One benefit of such capability is allowing various kinds of 3D Graphics API Shader compute models to run efficiently on GEN. Another benefit is allowing high throughput of media applications, which tend to operate on byte or word data elements. This can be illustrated by the example shown in Region Parameters and Region Parameters. As shown in Region Parameters, a sequence of SIMD instruction is executed on a conventional load/store based superscalar machine with SIMD instruction extension. The data parallelism can be achieved by first level of loop unrolling. As shown, there is a second level of loop for the task. Before a given SIMD compute instruction, Process (i), can proceed, there might be a load, a data rearrange and a data unpack (and conversion) instruction to load and prepare the input data. After the compute instruction is complete, it might also require pack, re-arrange and store instructions, to format and save the same to memory. At the loop, other scalar computations such as loop count and address generation may be needed. For the same program, when the data can fit in the large GEN GRF register file, the outer loop may be unrolled for GEN. Here one or a few block loads (using send instruction) may be sufficient to move the working set into GRF. Then the data shuffle can be combined with the processing operation with region-based addressing capability. Per operand float type and mixed data type operation may also allow GEN to combine data conditioning operations with computing operations. These techniques in GEN architecture help to achieve high compute efficiency and throughput for graphics and media applications. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 57 Conventional SIMD Instruction Sequence GEN SIMD Instruction Sequence for the Same Program In a GEN instruction, each operand defines a region in the register file. A region may contain multiple data elements. Each data element is assigned to an execution channel in the EU. The total number of Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 58 data elements of a region is called the size of the region, or the size of the operand. The number of execution channels is called the execution size (ExecSize), which is specified in the instruction word. ExecSize determines the size of region for source and destination operands in an instruction.  For an instruction with two source operands, the sizes of the two source operands must be the same.  The size of a destination operand generally matches the execution size, therefore equals to the number of source operand(s) in the same instruction. o Exception of this rule is present for the integer reduction instructions (such as sad2 and sada2) where the destination area is smaller than the source area. Regions are generalized 2-dimensional (2D) arrays in row-major order. The first dimension is named the horizontal dimension (data elements within a row) and the second dimension is termed the vertical dimension (data elements in a column). Here, horizontal/vertical and row/column are just symbolic notations. When the GRF registers are viewed as a row-major 2D array of memory, such a notation normally matches well with the geometric locations of the data elements of an operand. However, as the register region is fully described by the parameters discussed below, the data elements of a register region may not form a regular rectangular shape. For example, Vertical Stride parameter is allowed to be smaller than Horizontal Stride, making the rows of a register region interleave with each other. It should also note that the meanings of horizontal/vertical here is different than that used for the flag control in the Flag Registers section. Specifically, a region-based description of a source operand can take the following format RegFile RegNum.SubRegNum:type Parameters are as the follows.  Register Region Origin (RegFile, RegNum and SubRegNum): This set of parameters, including the register file, RegFile, the register number, RegNum, and the subregister number, SubRegNum, describes the register region origin, which is the location of the first data element of the operand. RegNum is in unit of 256-bit and SubRegNum is in unit of the data element size.  Width (Width): Width specifies the number of data elements along the horizontal dimension, or the number of data elements of a row.  Horizontal Stride (HorzStride): HorzStride specifies the step size between two adjacent data elements within a row. It is in unit of data element size, which is determined by the data element Type.  Vertical Stride (VertStride): VertStride specifies the step size between two adjacent data elements along the vertical dimension (or the step size between two rows). It is again in unit of data element size, which is determined by the data element Type.  Data Element Type (Type): Type specifies numeric data type (float, word, byte, etc.) of the data elements. All data elements within a region must have the same type. GRF register file consists of a sequence of 256-bit registers. When viewing the register file (GRF for example) as a sequence of 256-bit aligned registers, RegNum field provides the register number, thus for the name. SubRegNum provides the sub-field addressing within a register. However, when viewing the register file as a byte addressable memory array, (RegNum and SubRegNum) is just a byte address within the register file with SubRegNum providing the lower 5 bits and RegNum providing the higher bits. The execution size is specified for each instruction by the parameter ExecSize. The size of the vertical dimension is ExecSize/Width, based on the rule that the size of regions must equal to the execution size. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 59 Region Parameters depicts the register region description. The example shows a register region of r4.1<16;8,2>:w, where the shaded fields denote the data elements in the region and the numbers in these fields are the execution channel assignments. The register region assumes that an ExecSize of 16 is set for the instruction. Each data element is a word (as noted by the type field “:w”). The origin of the region is at the second word of r4, denoted by r4.1. Each row of the region has 8 data elements (words) that are 2 data elements (words) apart. The distance between two rows is 16 words. Note that the region shown is for illustration purpose only. It does not represent a typical usage model nor a performance optimized mode. An example of a register region (r4.1<16;8,2>:w) with 16 elements Region Parameters shows another example where the rows are interleaved. The region, having word data elements, starts at location r5.0:w. HorzStride, the distance within a row, is 2 words. So the second element (channel number 1) is at location 5.2:w. And there are 8 elements per row. VertStride, the distance between two rows, is only 1 word, which is less than HorzStride. Therefore, the first element of the second row (channel number 8) is at r5.1:w, just next to channel number 0. It is clear from the picture that the two rows are interleaved. By varying the region parameters, reader may construct other configurations. The next section provides more details on the region-based register addressing. However, there are restrictions imposed by hardware implementation, which can be found in the later sections of this chapter. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 60 A 16-element register region with interleaved rows (r5.0<1;8,2>:w) Without considering the source channel swizzle and destination register region description, the above row-major-order region description provides the data assignment to each execution channel. The following pseudo code computes the addresses of data elements assigned to execution channels for a special case when the destination register is aligned to 256-bit register boundary. // Input: Type: ub | b | uw | w | ud | d | f | v //RegNum: In unit of 256-bit register //SubRegNum: In unit of data element size //ExecSize, Width, VertStride, HorzStride: In unit of data elements // Output: Address[0:ExecSize-1] for execution channels int ElementSize = (Type==“b”||Type==“ub”) ? 1 : (Type==“w”|Type==“uw”) ? 2 : 4; int Height = ExecSize / Width; int Channel = 0; int RowBase = RegNum<<5 + SubRegNum * ElementSize; for (int y=0; y:type The destination operand is only allowed to have a 1 dimensional region. The Register Region Origin and Type are the same as for a source operand. The total number of elements is given by ExecSize. However, only HorzStride is required to describe the 1D region, not VertStride and Width. As a source register region may cross multiple physical GRF registers, an instruction with such source operands may take more than two execution cycles to gather source data elements for execution. The destination register region is restricted to be within a physical GRF register. In other words, destination scatter writes over multiple registers are not supported. 3.3.6 Region Addressing Modes There are two different register addressing modes: Direct register addressing and register-indirect register addressing. Depending on the register region description, the register-indirect register addressing mode can be further divided into three usages: 1x1 index region where only the origin of register region is provided by the address register, Vx1 index region where the offset of each row of the register region is provided by an address register, VxH index region where the offset of each data element is provided by an address register. 3.3.6.1 Direct Register Addressing In this mode, all register region parameters are specified for an operand using fields in the instruction word. Direct Register Addressing and Direct Register Addressing are two examples of direct register addressing. For the example in Direct Register Addressing, all operands are 2D rectangular regions having the same size of 16 data elements. The two source operands, Src0 and Src1, have 16 bytes. The destination operand, Dst, has 16 words. There are 8 elements in a row for Src0 and Src1. The vertical stride of 16 bytes for Src0 and Src1 indicates that the first element and the 9’th element are 16 bytes apart in the register file. Note that Src0 falls into the 256-bit physical GRF register starting at r1.0, but Src1 crosses the 256-bit physical GRF register boundary between r2 and r3. The numbers in the shaded regions are the values of the data elements. Observing the upper right corners of the source/destination regions (first data element), we have C = 3+9. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 62 A region description example in direct register addressing For the example in Direct Register Addressing, the sizes of areas of Src0 and Src1 are the same, but Src0 contains a vector of replicated scalars. With HorzStride = 0 and Width = 8, the first row of 8 elements in Src0 is a replication of the byte at r1.14. Comparing ExecSize of 16 to Width of 8 indicates that there is a second row of 8 elements in Src0. With VertStride = 16, the second row in Src0 is a replication of the byte at r1.20 (20 = 14+16). Effectively, the 16 data elements of Src0 are {1,1,1,1,1,1,1,1, 4,4,4,4,4,4,4,4}. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 63 A region description example in direct register addressing with src0 as a vector of replicated scalars 3.3.6.2 Register-Indirect Register Addressing with a 1x1 Index Region In the register-indirect register addressing mode with 1x1 index region, the region origin is provided by the content of the address register, the rest of region parameters are provided by the fields in the instruction word. Register indirect Register Addressing with a 1x1 Index Region depicts an example for this addressing mode. For example, the presence of a full region description <16;8,1> for Src0 indicates that only the origin of the region is provided by the address register a0.0. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 64 An example illustrating register-indirect register addressing mode with a 1x1 index region 3.3.6.3 Register-Indirect Register Addressing with a Vx1 Index Region In the register-indirect register addressing mode with Vx1 index region, the horizontal dimension is described by the fields in the instruction word and the vertical dimension is described by an address register region. Specifically, the origin of each row of the data region is provided by the contents of an address register region. The rows are described by the width and the horizontal stride. The first address register is provided and the following contiguous address registers are for the following rows. The total number of address registers used is inferred from the parameters ExecSize and Width. Within the 16-bit address register, bits 15:5 determine RegNum and bits 4:0 determine SubRegNum. An example is provided in Register-Indirect Register Addressing with a Vx1 Index Region. The assembly syntax notion of a register region without vertical stride, <4,1>, corresponding to the special encoding of vertical stride of 0xF in the instruction word, indicates the VxH or Vx1 mode of indirect register addressing. In this case, the origin for each row of src0 is provided by the address register. As ExecSize/Width = 2, there are two address registers a0.0 and a0.1, each pointing to a row of 4 data elements. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 65 An example illustrating register-indirect-register addressing mode with a Vx1 index region (src0) 3.3.6.4 Register-indirect Register Addressing with a VxH Index Region In the register-indirect register addressing mode with VxH index region, the position of each data element is provided by the contexts in an address register region. This mode has the identical syntax as the Vx1 index region mode, and in fact, can be viewed as a special case of the Vx1 mode. When Width of the region is 1, the number of address registers used equals ExecSize. An example is provided in Register indirect Register Addressing with a VxH Index Region. The absent of vertical stride in the region description <1,0> with width = 1 indicates that the origin for each row of 1 data element of Src0 is provided by the address register. As ExecSize/Width = 8, there are 8 address registers from a0.0 to a0.7, each pointing to a single data elements. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 66 An example illustrating register-indirect register addressing mode with a VxH index region (Src0). 3.3.7 Access Modes There are two basic GEN register access modes controlled by a single bit instruction subfield called Access Mode.  16-byte Aligned Access Mode (align16): In this mode, the origins of all operands (sources and destination), whether it is by direct addressing or register-indirect addressing, are 16-byte aligned. For example a row in the region description starts at 16-bype aligned and the width the row must be 4 and the 4 data elements within a row must span 16-bytes. In this access mode (and with other restrictions put forward later), full-channel swizzle for both source operands and per-channel mask for destination operand are supported on a 4-component basis. In other words, the control and setting of full source swizzle and destination mask are repeated for every 4 components up to total of ExecSize channels. o The align16 access mode can be used for AOS operations. See examples provided in the Primary Usage Model section for SIMD4x2 and SIMD4x1 modes of operation to support 3D API Vertex Shader and Geometric Shader execution.  1-byte Aligned Access Mode (align1): In this mode, the origins of all operands may be aligned to their data type and could be 1-byte if the operand is of byte type. In this access mode, full region register descriptions are supported, however, source swizzle or destination mask are not supported. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 67 o The align1 access mode can be used for SOA operations. See examples provided in the Primary Usage Model section for SIMD8 and SIMD16 modes of operation to support 3D API Pixel Shader. Many media applications also operate well in align1 access mode. 3.3.8 Execution Data Type The GEN architecture carries out arithmetic and logical operations using a smaller set of data types than the variety supported as source or destination operands. These are the execution data types. A particular arithmetic or logical instruction has one execution data type, from those listed in the table. Execution Data Types Type Description W Word. 16-bit signed integer. D Doubleword. 32-bit signed integer. F Float. 32-bit single precision floating-point number. DF Double Float. 64-bit double precision floating-point number. The following rules explain the conversion of multiple source operand types, possibly a mix of different types, to one common execution type:  For floating-point sources, all source operands must have the same floating-point type, with the exception that a two-source floating-point instruction can have Float as the src0 type and VF (Packed Restricted Float Vector) as the immediate src1 type.  Mixing floating-point and integer source types is not allowed. Either all source types must be one floating-point type or all source types must be integer types.  Unsigned integers are converted to signed integers.  Byte (B) or Unsigned Byte (UB) values are converted to a Word or wider integer execution type.  If source operands have different integer widths, use the widest width specified to choose the signed integer execution type. Note that when the execution data type is an integer type, it is always a signed integer type. For integer execution types, extra precision is provided within the hardware, including the accumulators, so that conversions from unsigned to signed do not affect instruction correctness. 3.3.9 Register Region Restrictions A register region is described as packed if its elements are adjacent in memory, with no intervening space, no overlap, and no replicated values. If there is more than one element in a row, elements must be adjacent. If there is more than one row, rows must be adjacent. When two registers are used, the registers must be adjacent and both must exist. The following register region rules apply to the GEN implementation. Rules and restrictions for compressed instructions are in the Instruction Compression section. 1. General Restrictions Based on Operand Types There are these general restrictions based on operand types: A. Where n is the largest element size in bytes for any source or destination operand type, ExecSize * n must be <= 64. B. When the Execution Data Type is wider than the destination data type, the destination must be aligned as required by the wider execution data type and specify a HorzStride equal to the ratio Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 68 in sizes of the two data types. For example, a mov with a D source and B destination must use a 4-byte aligned destination and a Dst.HorzStride of 4. 2. General Restrictions on Regioning Parameters The mapping of data elements within the region of a source operand is in row-major order and is determined by the region description of the source operand, the destination operand, and the ExecSize, with these restrictions: A. ExecSize must be greater than or equal to Width. B. If ExecSize = Width and HorzStride ≠ 0, VertStride must be set to Width * HorzStride. C. If ExecSize = Width and HorzStride = 0, there is no restriction on VertStride. D. If Width = 1, HorzStride must be 0 regardless of the values of ExecSize and VertStride. E. If ExecSize = Width = 1, both VertStride and HorzStride must be 0. This defines a scalar. F. If VertStride = HorzStride = 0, Width must be 1 regardless of the value of ExecSize. G. Dst.HorzStride must not be 0. H. VertStride must be used to cross GRF register boundaries. This rule implies that elements within a ‘Width’ cannot cross GRF boundaries. 3. Region Alignment Rules A. In Direct Addressing mode, a source cannot span more than 2 adjacent GRF registers. B. A destination cannot span more than 2 adjacent GRF registers. C. When an instruction has a source region spanning two registers and a destination region contained in one register, one of the following must be true: i. The destination region is entirely contained in the lower OWord of a register. ii. The destination region is entirely contained in the upper OWord of a register. iii. The destination elements are evenly split between the two OWords of a register. D. When an instruction has a source region that spans two registers and the destination spans two registers, the destination elements must be evenly split between the two registers and each destination register must be entirely derived from one source register. Note: In such cases, the regioning parameters must ensure that the offset from the two source registers is the same. The examples below illustrate the behavior of the cases permitted: // Case (a) First 8 elements are from r12 to r10 and second from r13 to r11: mov (16) r10.0<2>:w r12<16;8,1>:w // The above instruction behaves the same as the following two instructions: mov (8) r10.0<2>:w r12<16;8,1>:w mov (8) r11.0<2>:w r13<16;8,1>:w // Case (b) First 8 elements from r12.8 to r10 and second from r13 to r11: mov (16) r10.0<2>:w r12.8<16;8,1>:w // The above instruction behaves the same as the following two instructions: mov (8) r10.0<2>:w r12.8<16;8,1>:w mov (8) r11.0<2>:w r13.8<16;8,1>:w The following examples indicate cases that are not allowed: // Not allowed, because the source has 12 elements from r12 and 4 from r13: mov (16) r10.0<2>:w r12.4<4;4,1>:w Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 69 // Not allowed, because the destination has 6 elements in r10 and 10 in r11: mov (16) r10.2<2>:w r12<16;8,1>:w // Not allowed, because the source has only one GRF register // but the destination spans two registers: mov (16) r10.0<2>:w r12.0<8;8,1>:w E. When destination spans two registers, the source MUST span two registers. The exception to the above rule: i. When source is scalar, the source registers are not incremented. ii. When source is packed integer Word and destination is packed integer DWord, the source register is not incremented by the source sub register is incremented. The examples below illustrate the behavior of the cases permitted: // Case (a) Scalar source: mov (16) r10.0<2>:w r12.0<0;1,0>:w // The above instruction behaves the same as the following two instructions: mov (8) r10.0<2>:w r12.0<0;1,0>:w mov (8) r11.0<2>:w r12.0<0;1.0>:w // Case (b) First 8 elements from r12 to r10 and second from r12.8 to r11: mov (16) r10.0<1>:d r12<8;8,1>:w // The above instruction behaves the same as the following two instructions: mov (8) r10.0<1>:d r12<8;8,1>:w mov (8) r11.0<1>:d r12.8<8;8,1>:w F. With the exception of the two rules in “Special Cases for Byte Operations” below, all destination data elements must be aligned to the size for the execution data type of the instruction. For example, if one of the source operands is in DWord mode (a float, a signed or unsigned DWord integer), the execution data type is either float or signed DWord integer. Therefore the destination data type must be DWord-aligned. This rule has the following two implications: i. The destination sub-register must be aligned to the size of the execution data type. ii. If ExecSize is greater than 1, Dst.HorzStride * sizeof(Dst.DstType) must be greater than or equal to the size of the execution data type. 4. Special Cases for Byte Operations A. When the destination type is byte (UB or B) only a ‘raw move’ using the mov instruction supports a packed byte destination register region: Dst.HorzStride = 1 and Dst.DstType = (UB or B). This packed byte destination register region is not allowed for any other instructions, including a ‘raw move’ using the selinstruction, because the sel instruction is based on Word or DWord wide execution channels. B. There is a relaxed alignment rule for byte destinations. When the destination type is byte (UB or B), destination data types can be aligned to either the lowest byte or the second lowest byte of the execution channel. For example, if one of the source operands is in word mode (a signed or unsigned word integer), the execution data type will be signed word integer. In this case the destination data bytes can be either all in the even byte locations or all in the odd byte locations. This rule has two implications illustrated by this example: // Example: mov (8) r10.0<2>:b r11.0<8;8,1>:w Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 70 mov (8) r10.1<2>:b r11.0<8;8,1>:w // Dst.HorzStride must be 2 in the above example so that the destination // subregisters are aligned to the execution data type, which is :w. // However, the offset may be .0 or .1. // This special handling applies to byte destinations ONLY. 5. Special Requirements for Handling Double Precision Data Types A. In Align1 mode, all regioning parameters like stride, execution size, and width must use the syntax of a pair of packed floats. The offsets for these data types must be 64-bit aligned. The execution size and regioning parameters are in terms of floats. // Example: mov (8) r10.0<1>:df r11.0<8;8,1>:df // The above instruction moves four double floats. B. In Align16 mode, all regioning parameters must use the syntax of a pair of packed floats, including channel selects and channel enables. // Example: mov (8) r10.0.xyzw:df r11.0.xyzw:df // The above instruction moves four double floats. The .x picks the // low 32 bits and the .y picks the high 32 bits of the double float. C. When using Align16 mode for conversion of data elements of different sizes, both source and destination must be one register each. 6. Regioning Rules for Register Indirect Addressing A. When the execution size and destination regioning parameters require two registers, each register is pointed to by adjacent index registers. // Example: mov (16) r[a0.0]:f r10:f // The above instruction behaves the same as the following two instructions: mov (8) r[a0.0]:f r10:f mov (8) r[a0.1]:f r11:f B. When the destination requires two registers and the sources are indirect, the sources must use 1x1 regioning mode. In addition, the sources are assembled from two GRF registers each accessed by adjacent index registers in 1x1 regioning modes. The data for each destination GRF register is entirely derived from one source register. Note: There is an exception to this rule. When source is scalar, the indirect address is not incremented. // Example: // Case (a): add (16) r[a0.0]:f r[a0.2]:f r[a0.4]:f // The above instruction behaves the same as the following two instructions: add (8) r[a0.0]:f r[a0.2]:f r[a0.4]:f add (8) r[a0.1]:f r[a0.3]:f r[a0.5]:f // Each access, source and destination, is a 1x1 regioning access. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 71 // Case (b): add (16) r[a0.0]:f r[a0:2]:f r[a0.4]<0;1,0>:f // The above instruction behaves the same as the following two instructions: add (8) r[a0.0]:f r[a0.2]:f r[a0.4]<0;1,0>:f add (8) r[a0.1]:f r[a0.3]:f r[a0.4]<0;1,0>:f // Note that the src1 indirect address does not change. C. Indirect addressing on src1 must be a 1x1 indexed region mode. D. When a Vx1 or a VxH addressing mode is used on src0, the destination must use ONLY one register. E. Indirect addressing on the destination must be a 1x1 indexed region mode. F. Data elements referenced by a single index within a source region cannot cross a 256-bit register boundary. This applies to a register region with a single index or with multiple indices. G. A register region with multiple indices may access multiple registers if the data elements associated with each index follow the above-mentioned rule. // Example: mov (16) r10.0:w r[a0.0]<2,2>:w // This instruction gathers source elements pointed to by up to 8 // different physical GRF registers, where two elements accessed // by each indirect access are from one physical GRF register. 7. Special Restrictions A. In Align16 access mode, SIMD16 is not allowed for DW operations and SIMD8 is not allowed for DF operations. B. When an instruction is SIMD32, the low 16 bits of the execution mask are applied for both halves of the SIMD32 instruction. If different execution mask channels are required, split the instruction into two SIMD16 instructions. C. Instructions with condition modifiers must not use SIMD32. D. All flow control (branching) instructions must use the Align1 access mode. 3.3.10 Destination Operand Description 3.3.10.1 Destination Region Parameters Based on the above restrictions, a subset of register region parameters are sufficient to describe the destination operand:  Destination Register Origin o Destination Register Number and Destination Subregister Number for direct register addressing mode o A Scalar Destination Register Index for register-indirect-register addressing mode  Destination Register ‘Region’ – Note that destination register region does not have full region description parameters o Destination Horizontal Stride Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 72 3.4 SIMD Execution Control 3.4.1 Predication Predication is the conditional SIMD channel selection for execution on a per instruction basis. It is an efficient way of dynamic SIMD channel enabling without paying branch instruction overhead. When predication is enabled for an instruction, a Predicate Mask (PMask), which contains 16-bit channel enables, is generated internally in EU. Note that PMask is not a software visible register. It is provided here to explain how SIMD execution control works. PMask generation is based on the Predication Control (PredCtrl) field, Predication Inversion (PredInv) field and the flag source register in the instruction word. See Instruction Summary chapter for definition of these fields. Predication shows the block diagram of the hardware logic to generate PMask. PMask is generated based on combinatory logic operation of the bits in the flag register. Instruction field PredCtrl controls the horizontal evaluation unit and vertical evaluation unit. MUX A in the figure selects whether horizontally- evaluated results or vertically-evaluated results are sent to the Predication Invertion unit. The PredInv field controls the Prediction Inversion unit. Either one 16-bit flag subregister or the whole flag register may be selected to generate the PMask depending on the predication control modes. MUX B indicates that predication can be enabled and disabled. Predication can be grouped into the following three categories. Predication functionality also depends on the Access Mode of the instruction.  No predication: Of course, predication can be disabled. This is the most commonly used case.  Predication with horizontal combination: the predicate mask is generated based on combinatory logic operation of bits within a selected flag subregister.  Predication with vertical combination: the predicate mask is generated based on combinatory logic operation of bits across flag multiple subregisters. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 73 Generation of predication mask 3.4.2 No Predication When PredCtrl field of a given instruction is set to 0 (“no predication”), it indicates that no predication is applied to this instruction. Effectively, the resulting PMask is all 1’s. This is shown by the 2:1 multiplexer B controlled by the Pred Enable signal in Predication. Where predication is not enabled for an instruction, multiplex B is selected to output 0xFF to PMask. 3.4.3 Predication with Horizontal Combination Predication with horizontal combination inputs the 16 bits of a single flag subregister (f0.0:uw or f0.1:uw) and passes them through combinatory logic of the Horizontal Evaluation unit to create PMask. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 74 The simplest combination is ‘no combination’ – the same 16 bits from selected flag subregister are output to MUX A. In this case, a bit in the selected flag subregister controls the conditional execution of the corresponding execution channel. Let the selected flag subregister be denoted as f0.#, the following pseudo code describes the predicate mask generation for predication with sequential flag channel mapping. If (PredCtrl == “Sequential flag channel mapping”) { For (ch=0; ch<16; ch++) PMask[ch] = (PredInv == TRUE) ? ~f0.#[ch] : f0.#[ch]; } More complex horizontal evaluation is based on channel grouping. A group of adjacent channels (bits from flag subregister) are evaluated together and a single bit is replicated to the group. The size of groups is in power of 2. The supported combination depends on the Access Mode of an instruction. In Align16 access mode, horizontal combination is based on 4-channel groups.  Channel replication: PredCtrl of ‘.x’, ‘.y’, ‘.z’ and ‘.w’ select a single channel from each 4-channel group and replicate it as the output for the group. For example, PredCtrl = ‘.x’ means that channel 0 in each group is replicated.  OR combination: PredCtrl of ‘.any4h’ means that if any of the channel in a group is enabled, outputs for the 4 channels in the group are all enabled.  AND combination: PredCtrl of ‘.all4h’ means that only when all of the channels in a group are enabled, the output for the group is enabled. These combinations in Align16 mode can be described by the following pseudo-code. If (Access Mode == Align16) { For (ch = 0; ch < 16; ch += 4) Switch (PredCtrl) { Case ‘.x’: bTmp = f0.#[ch]; break; Case ‘.y’: bTmp = f0.#[ch+1]; break; Case ‘.z’: bTmp = f0.#[ch+2]; break; Case ‘.w’: bTmp = f0.#[ch+3]; break; Case ‘.any4h’: bTmp = f0.#[ch] | f0.#[ch+1] | f0.#[ch+2] | f0.#[ch+3]; break; Case ‘.all4h’: bTmp = f0.#[ch] & f0.#[ch+1] & f0.#[ch+2] & f0.#[ch+3]; break; } bTmp = (PredInv == TRUE) ? ~bTmp : bTmp; PMask[ch] = PMask[ch+1] = PMask[ch+2] = PMask[ch+3] = bTmp; } } In Align1 access mode, horizontal combination is based on AND combination ‘.any#h’ and OR combination ‘.all#h’ on channel groups with various sizes, where # is the number of channels in a group ranging from 2 to 16. This is described by the following pseudo-code. If (Access Mode == Align1) { Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 75 Switch (PredCtrl) { Case ‘.any2h’: groupSize = 2; = ‘|’; break; Case ‘.all2h’: groupSize = 2; = ‘&’; break; Case ‘.any4h’: groupSize = 4; = ‘|’; break; Case ‘.all4h’: groupSize = 4; = ‘&’; break; Case ‘.any8h’: groupSize = 8; = ‘|’; break; Case ‘.all8h’: groupSize = 8; = ‘&’; break; Case ‘.any16h’: groupSize = 16; = ‘|’; break; Case ‘.all16h’: groupSize = 16; = ‘&’; break; } For (ch = 0; ch < 16; ch += groupSize) { For (inc = 0, bTmp = FALSE; inc < groupSize; inc ++) bTmp = bTmp f0.#[ch+inc]; For (inc = 0; inc < groupSize; inc ++) PMask[ch+inc] = bTmp; } } 3.4.4 Predication with Vertical Combination Predication with vertical combination uses both flag subregister as inputs. The AND or OR combination is across the subregisters on a channel by channel basis. This is shown by the following pseudo-code. If (Access Mode == Align1) { For (ch = 0; ch < 16; ch ++) { If (PredCtrl == ‘any2v’) PMask[ch] = f0.0[ch] | f0.1[ch] Else If (PredCtrl == ‘any2h’) PMask[ch] = f0.0[ch] & f0.1[ch] } } 3.5 End of Thread There is no special instruction opcode (such as an END instruction) to cause the thread to terminate execution. Instead, the end of thread is signified by a send instruction with the end-of-thread (EOT) sideband bit set. Upon executing a send instruction with EOT set, the EU stops on the thread. Upon observing an EOT signal on the output message bus, the Thread Dispatcher makes the thread’s resource available. If a thread uses pre-allocated resource managed by a fixed function, such as URB handles and Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 76 scratch memory, some fixed function protocol also requires the thread to terminate with the message header phase to carry the information in order for the fixed function to release the pre-allocated resource. EU hardware guarantees that if a terminated thread has in-flight read messages or loads at the time of ‘end’ that their writebacks will not interfere with either other threads in the system or new threads loaded in the system in the future. More details can be found in the send instruction description in Instruction Reference chapter. 3.6 Assigning Conditional Flags Instructions can output two sets of conditional signals, one set from before the outputs clamping/re- normalizing/format conversion logic, we call this the pre conditional signals. The second set is generated from the final results after clamping and re-normalizing/format conversion logic, and we call this the post conditional signals. The post conditional signals are used for fusing the DirectX compare instruction. Note: The flags generated from the post conditional signals should be equivalent to the flags generated by a separate cmp instruction after the current arithmetic instruction. The pre conditional signals are used to generated flags for cmp/cmpn instructions only, this logically does the compare of the two input sources. The post conditional signals are used to generated flags for all the other arithmetic instructions, this logically does the compare of the result with zero. cmpn with both sources as NaNs is a don't care case as this doesn't impact the MIN/MAX operations. The pre conditional signals include the following:  pre_sign bit: This bit reflects the sign of the computed result before going through any kind of clamping, normalizing, or format conversion logic.  pre_zero bit: This bit reflects whether the computed result is zero before any kind of clamping, normalizing, or format conversion logic. The post conditional signals include the following:  post_sign bit: This bit reflects the sign of the final result after all the clamping, normalizing, or format conversion logic.  post_zero bit: This bit reflects whether the final result is zero after all the clamping, normalizing, or format conversion logic.  OF bit: This bit reflects whether an overflow occured in any of the computation of the current instruction, including clamping, re-normalizing, and format conversion.  NC bit: The NaN computed bit indicates whether the computed result is not a number. It carries valid information for instructions operating on floating point values. For an operation on integer operands, this bit is always 0.  NS0 bit: The NaN Source 0 bit indicates whether src0 of an execution channel is not a number. It carries valid information for instructions operating on floating point values. For an operation on integer operands, this bit is always 0.  NS1 bit: The NaN Source 1 bit indicates whether src1 of an execution channel is not a number. It carries valid information for instructions operating on floating point values. For an operation on integer operands, this bit is always 0. For an operation with one source operand, this bit is also set to 0. This bit is only used for the comparison instruction cmpn, which is specifically provided to emulate MIN/MAX operations. For any other instructions, this bit is undefined.  Note that the bits generated at the output of a compute are before the .sat. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 77 Flag Generation for cmp Instructions (The Supported Conditional Modifiers are .e, .ne, .g, .ge, .l, and .le.) Conditional Modifier Meaning Resulting Flag Value (for an execution channel) .e Equal-to (pre_zero & ! (NS0 | NS1)). This conditional modifier tests whether the two sources are equal. If either source is NaN (i.e. NC is true), the flag is forced to false. .ne Not-Equal-to ! (pre_zero & ! (NS0 | NS1)). This conditional modifier test whether the two sources are equal. It takes exactly the reverse polarity as the modifier .e. .g Greater-than ( ! pre_sign & ! pre_zero & ! (NS0 | NS1)). This conditional modifier tests whether src0 is greater than src1. If either source is a NaN (i.e. NC is true), the flag is forced to false. .ge Greater-than-or- ((! pre_sign | pre_zero) & ! (NS0 | NS1)). This conditional modifier tests whether equal-to src0 is greater than or equal to src1. If either source is a NaN (i.e. NC is true), the flag is forced to false. .l Less-than (pre_sign & !pre_zero & ! (NS0 | NS1)). This conditional modifier tests whether src0 is less than src1. If either source is a NaN (i.e. NC is true), the flag is forced to false. .le Less-than-or- ((pre_sign | pre_zero) & ! (NS0 | NS1)). This conditional modifier tests whether equal-to src0 is less than or equal to src1. If either source is a NaN (i.e. NC is true), the flag is forced to false. Flag Generation for cmpn Instructions (The Supported Conditional Modifiers are .ge, and .l) Conditional Modifier Meaning Resulting Flag Value (for an execution channel) .ge Greater-than- (! pre_sign | (NS1 & (Opcode == cmpn | Opcode == sel with CMod))) & ! (NS0 & or-equal-to (Opcode == cmpn)). This conditional modifier tests whether src0 is greater than or equal to src1. If src1 is a NaN (i.e. NS is true), the flag is forced to true. .l Less-than (pre_sign | (NS1 & (Opcode == cmpn | Opcode == sel with CMod))) & ! (NS0 & (Opcode == cmpn)). This conditional modifier tests whether src0 is less than src1. If src1 is a NaN (i.e. NS is true), the flag is forced to true. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 78 Flag Generation for All Instructions Other than cmp/cmpn Instructions (The Supported Conditional Modifiers are .e, .ne, .g, .ge, .l, .le, .o, and .u.) Conditional Modifier Meaning Resulting Flag Value (for an execution channel) .e Equal-to (post_zero & ! NC). This conditional modifier tests whether the result is equal to zero. If either source is NaN (i.e. NC is true), the flag is forced to false. .ne Not-Equal-to ! (post_zero & ! NC). This conditional modifier test whether the result is not equal to zero. It takes exactly the reverse polarity as modifier .e. .g Greater-than (! post_sign & ! post_zero & ! NC). This conditional modifier tests whether result is greater than zero. If either source is a NaN (i.e. NC is true), the flag is forced to false. .ge Greater-than-or- ((! post_sign | post_zero) & ! NC). This conditional modifier tests whether result equal-to is greater than or equal to zero. If either source is a NaN (i.e. NC is true), the flag is forced to false. .l Less-than (post_sign & ! post_zero & ! NC). This conditional modifier tests whether result is equal to zero. If either source is a NaN (i.e. NC is true), the flag is forced to false. .le Less-than-or- ((post_sign | post_zero) & ! NC). This conditional modifier tests whether result equal-to is equal to or less than zero. If either source is a NaN (i.e. NC is true), the flag is forced to false. .o Overflow OF. This conditional modifier tests whether the computed result causes overflow – the computed result is outside the range of the destination data type. All other internal conditional signals are ignored. .u Unordered NC. This conditional modifier tests whether the computed result is a NaN (unordered). All other internal conditional signals are ignored. 3.7 Destination Hazard The architecture has built-in hardware to avoid destination hazard. Destination Hazard stands for the risk condition when multiple operations are trying to write to the same destination and the result of the destination may be ambiguous. This may or may not happen on GEN for two instructions with the same destination, or with destinations that have overlapped register region, depending on the ordering of the arrival of destination results. Let’s consider two instructions in a thread with potential destination hazard. There may be other instruction between them as long as there is no instruction sourcing the same destination. Using register scoreboards, GEN hardware automatically takes care of the destination hazard by not issuing the second instruction until the destination scoreboard is cleared. However, for certain cases, in fact for most cases, such destination hazard indicated by the Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 79 register scoreboard is false, causing unnecessary delay of instruction issuing. This may result in lower performance. The destination dependency control field in the instruction word {NoDDClr, NoDDhk} allows software to selectively override such hardware destination dependency mechanism. Such performance optimization hooks must be used with extreme caution. When it is not certain that it is a false destination hazard, the programmer should rely on hardware to resolve the dependency. As the destination dependency control field does not apply to send instruction, there is only one condition that a programmer may use the {NoDDClr, NoDDChk} capability.  If none of the two instructions is send, there CANNOT be any destination hazard. This is because instructions within a thread are dispatched in order (single-issued) and the execution pipeline is in- order and has a fixed latency. When a sequence of NoDDChk and NoDDClr are used, the last instruction that completes the scoreboard clear must have a non-zero execution mask. This means, if any kind of predication can change the execution mask or channel enable of the last instruction, the optimization must be avoided. This is to avoid instructions being shot down the pipeline when no writes are required. Example: (f0.0) mov r10.0 r11.0 {NoDDClr} (-f0.0) mov r10.0 r11.0 {NoDDChk, NoDDClr} In the above case, if predication can disable all writes to r10 for the second instructions, the instruction maybe shot down the pipeline resulting in un-deterministic behavior. Hence, This optimization must not be used in these cases. 3.8 Non-present Operands Some instructions do not have two source operands and one destination operand. If an operand is not present for an instruction the operand field in the binary instruction must be filed with null. Otherwise, results are unpredictable. Specifically, for instructions with a single source, it only uses the first source operand src0. In this case, the second source operand src1 must be set to null and also with the same type as the first source operand src0. It is a special case when src0 is an immediate, as an immediate src0 uses DW3 of the instruction word, which is normally used by src1. In this case, src1 must be programmed with register file ARF and the same data type as src0. 3.9 Instruction Prefetch Due to prefetch of the instruction stream, the EUs may attempt to access up to 8 instructions (128 bytes) beyond the end of the kernel program – possibly into the next memory page. Although these instructions will not be executed, software must account for the prefetch in order to avoid invalid page access faults. One possible (though inefficient) solution would be to pad the end of all kernel programs with 8 NOOP instructions. A more efficient approach would be to ensure that the page after all kernel programs is at least valid (even if mapped to a dummy page). Note that the General State Access Upper Bound field of the STATE_BASE_ADDRESS command can be used to prevent memory accesses past the end of the General State heap (where kernel programs must reside). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 80 4. Exceptions The Architecture defines a basic exception handling mechanism for several exception cases. This mechanism supports both normal operations such as extensions of the mask-stack depth, as well as detecting some illegal conditions . Exception Types Type Trigger / Source Sync/Async Recognition Software Exception Thread code Synchronous Breakpoint  A bit in the instruction word Synchronous  Breakpoint IP match  Breakpoint Opcode match Hardware Synchronous Illegal Opcode Halt MMIO register write Asynchronous Context Save/Restore Preemption Interrupt Asynchronous Threads may choose which exceptions to recognize and which to ignore. This mask information is specified on a per-kernel basis in fixed function state generated by the driver, and delivered to the EU as part of a new thread dispatch. Upon arrival at the EU, the exception-mask information is used to initialize the exception enable fields of that thread's cr0.1 register, which controls exception recognition. This register is instantiated on a per-thread basis, allowing independent control of exception type recognition across hardware threads. The exception enable bits in the cr0.1 register are read/write, and thus can be enabled/disabled via software at any time during thread execution. The exception handling mechanism relies on the System Routine, a single subroutine that provides common exception handling for all threads on all EUs in the system. This System Routine is defined per- context and is identified via a System IP (SIP) register in context state. At the time of each context switch, the appropriate SIP for that context is loaded into each EU, allowing each context to have custom implementation of exception handling routines if so desired. 4.1 Exception-Related Architecture Registers Exception-related registers are architecture registers cr0.0 through cr0.2. These registers are instantiated on a per-thread basis providing each hardware thread with unique control over exception recognition and handling. The registers provide the capability to mask exception types, determine the type of raised exception, store the return address, and control exiting from the System Routine back to the application thread. Many of the bits in these registers are manipulated by both hardware and software. In all cases, the read/write operations by hardware and software occur at exclusive times in a thread's lifetime, thus there is no need for atomic read-modify-write operations when accessing these registers. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 81 4.2 System Routine The following diagram illustrates the basic flow of exception handling and the structure of the System Routine. 4.2.1 Invoking the System Routine The System Routine is invoked in response to a raised exception. Once an exception is raised, no further instructions from the application thread are issued until the System Routine has executed and returned control back to the application thread. After an exception is recognized by hardware, the EU saves the thread's IP into its AIP register (cr0.2), and then moves the System Routine offset, SIP, into the thread's IP register. At this point the next instruction issued for that thread is the first instruction of the System Routine. The System Routine maintains the same execution priority, GRF register space, and thread state as the application thread from which it is invoked. Due to assuming the same priority, there may be significant Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 82 absolute time between an exception being raised and invoking the System Routine, as other higher priority threads within the EU continue to execute. From a thread's perspective, once an exception is recognized, the next instruction issued is from the System Routine. At the time of System Routine invocation, there may still be outstanding registers in-flight from the application thread. Depending on the instruction sequence in the System Routine, an in-flight register may be referenced by the System Routine and cause a register-in-flight dependency. These dependencies are honored by the System Routine and may cause the System Routine to be suspended until the register retires. Exception processing is not nested within the System Routine. If a future exception is detected while executing the System Routine, the exception is latched into cr0.1, but does not cause a nested re- invocation of the System Routine. The exception recognition hardware recognizes only one outstanding exception of each type; i.e., once a specific exception type is detected and latched in cr0.1, and until the exception is cleared, any further exception of that type is lost. Accumulators are not natively preserved across the System Routine. To make sure the accumulators are in the identical state once control is returned to the application thread, the System Routine must either set the Accumulator Disable bit of cr0.0 before using any instruction that modifies an accumulator, or save and restore the accumulators (using GRF registers or system thread scratch memory) around the System Routine. Saving and restoring accumulators, including their extended precision bits, can be accomplished by a short series of moves and shifts of the accumulator register. Also note that the state of the Accumulator Disable bit itself must be preserved unless, by convention, the driver software limits its manipulation to only the System Routine. Further, upon System Routine entry, the execution-related masks (Continue, Loop, If, and Active masks, contained in the Mask Register) will remain set as they were in the application thread. Thus only a subset of channels may be active for execution. To enable execution on all channels, the System Routine may choose to use the instruction option ‘NoMask’, or may choose to set the mask registers to the desired value so long as it saves/restores the original masks upon System Routine entry/exit. Similarly there is no hardware mechanism to preserve flags, mask-stacks, or other architecture registers across the System Routine. The System Routine must ensure that these values are preserved (see the Conditional Instructions Within the System Routine section for related information). 4.2.2 Returning to the Application Thread Prior to returning control to the application thread, the System Routine should clear the proper Exception Status and Control bit in cr0.1. Failure to do so forces the thread's execution to reenter the System Routine before any further instructions are executed from the application thread. (Note that single- stepping functionality is the one exception where the exception's Status and Control bit is not reset before exit.) The System Routine may choose to loop within a single invocation of the System Routine until all pending exceptions are serviced, or may choose to service exceptions one at a time (a simpler solution, but less efficient). The System Routine is exited, and control returned to the application thread, via a write to the Master Exception State and Control bit in cr0.0. Upon clearing this bit, the value of AIP (cr0.2) is restored to the thread’s IP register and, with no further exceptions pending, execution resumes at that address. The System Routine must follow any write to the Master Exception State and Control bit with at least one SIMD-16 nop instruction to allow control to transition. Throughout the System Routine, the AIP register maintains its value at the time the exception was raised unless directly modified by the System Routine. (See the AIP register definition for specifics on the IP value saved to AIP). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 83 4.2.3 System IP (SIP) The System IP (SIP) is the 16 byte-aligned offset of the first instruction of the System Routine, relative to the General State Base Address. SIP is assigned by the STATE_SIP command to the command streamer which updates SIP in the EU. When the System Routine is invoked, the application thread's current IP is first saved into the AIP field of cr0.2. The SIP address is then loaded into the thread's IP register and execution continues within the System Routine. Thus each invocation of the System Routine has a common entry point. Returning from the System Routine loads IP from AIP, continuing thread execution. 4.2.4 System Routine Register Space The System Routine uses the same GRF space as the thread that invokes it. As such all of the calling thread's registers and their contents are visible to the System Routine. Further, the System Routine must only use r0..r15 of the GRF, as a minimal thread may have requested and been allocated this few. If the System Routine requires more registers than this, the driver should establish a higher minimum allocation for all threads. The System Routine may encounter any residual register dependencies of the calling thread until such time that they clear by the return of in-flight writebacks. Only one 32-bit GRF location, r0.4, is reserved for System Routine use. This location is sufficient to allow the System Routine to calculate the appropriate offset of its private scratch memory in the larger system scratch memory space (as dictated by binding table entry 254). The offset is left as a driver convention, but is likely based on a combination of Thread and EU IDs (see the example system handler in the System Scratch Memory Space) section. Other than the reserved r0.4 register field, there is no explicit GRF register space dedicated to the System Routine, and any GRF needs must be accomplished via (a) convention between the System Routine and application code, or (b) the System Routine temporarily spilling the thread's GRF register contents to scratch memory and restoring those contents before System Routine exit. No persistent storage is automatically allocated to the System Routine, although a driver implementation may set aside part of system scratch memory for the System Routine. Any parameter passing to the System Routine (for use by software exceptions) is done via the GRF based on system thread/application thread convention. 4.2.5 System Scratch Memory Space There is a single unified system scratch memory space per context shared by all EUs. It is anticipated that block is further partitioned into a unique scratch sub-space per thread via conventions implemented in the System Routine, with each hardware thread having a uniform block size at a calculated offset from the base address. The block address for a thread can be based on an offset derived from the thread's execution unit ID and thread ID made available through the TID and EUID field of architecture register sr0.0. Per_Thread_Block_Size = System_Scratch_Block_Size / (EU_Count * Thread_Per_EU); Offset = (sr0.0.EID * Threads_Per_EU + sr0.0.TID) * Per_Thread_Block_Size; where in GEN: Threads_Per_EU = 4 EU_Count = 8 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 84 System_Scratch_Block_Size is a driver choice. Access to system scratch memory is performed through the Data Port via linear single register or block- based read/write messages. The driver may choose to use any binding table index for system scratch surface description. As a practical matter, the same index is expected to be used across all binding tables, as the index is typically hard coded in Data Port messages used within the System Routine coupled with the fact that a single System Routine is used for all threads. Read/write messages to the Data Port contain the address of the binding table (provided in r0 of all threads) and an offset, from which the Data Port calculates the final target address. It is expected that the system scratch memory space is allocated by the driver at context-create time and remains persistent at a constant memory address throughout a context's lifetime. 4.2.6 Conditional Instructions Within the System Routine It is expected that most, if not all, control flow within the System Routine is scalar in nature. If so, the System Routine should set SPF (Single Program Flow, cr0.0) to enable scalar branching. In this mode, conditional/loop instructions do not update the mask stacks and therefore do not have restrictions on their use nor require the save/restore of hardware mask stack registers. If SIMD branching is desired within the System Routine, special considerations must be taken. Upon entry to the System Routine, the depth of the mask stacks is unknown at that point, and may be near full. If so, a subsequent conditional instruction and its associated mask ‘push’ may cause a stack overflow. This would generate an exception within the system routine, an unsupported occurrence. To prevent this, if the System Routine uses SIMD conditional instructions, it must save the mask stacks prior to the first SIMD conditional instruction, and restore them after the last SIMD conditional instruction. As a general solution, it may be easiest to simply implement the save/restore as part of the entry/exit code sequence, using an available GRF register pair as a storage location. Once saved, the stacks should be reset to their empty condition, namely depth = 0 and top of stack = 0xFFFFFFFF. 4.2.7 Use of NoDDClr The instruction word defines an instruction option NoDDClr that overrides the native register dependency clearing mechanism of the typical instruction. When specified, NoDDClr does not clear, at register writeback time, the dependency placed on the destination register of the instruction. Use of this mechanism may provided increased performance when a kernel can guarantee no dependency issues between instructions, but may cause issues with exception handling in some circumstances as discussed here. Typically NoDDClr is used in an instruction series to enable a sequence of writes to sub-fields of a GRF register without paying a dependency penalty on each instruction. In this case, NoDDClr and NoDDChk are used across an instruction sequence to allow the first instruction to set the destination dependency, interior instructions to write to the GRF register without dependency checks, and the last instruction to clear the dependency. (This sequence is referred to as a NoDDClr code block going forward). By only allowing the last instruction to clear the dependency, program execution is prevented from going beyond a certain point until all writes of that sequence are known to retire. The problem arises if an exception is raised within a NoDDClr code block. In this case, there exists the potential for the System Routine to hang while attempting to save/restore a register used as a destination register by the NoDDCLr code block, as the outstanding dependency on that register will not clear until the final instruction of the NoDDCLr block is executed, sometime after the System Routine returns. Should the System Routine attempt to use that register, it hangs waiting on a dependency to be cleared by an instruction not yet issued. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 85 Note: This is a known condition and will in some cases not allow the full GRF contents to be externally visible in System Routine scratch space during a break or halt exception. To avoid this condition, guidelines are provided below for consideration. (Note that these are general guidelines, some of which can be alleviated through careful coding and register usage conventions and restrictions.)  NoDDClr code blocks should only be used where absolutely necessary.  Instructions that may generate exceptions should not be placed within NoDDClr blocks. This includes most conditional branch instructions (if, do, while, ...) .  If possible, use NoDDClr on registers high in the thread's register allocation (e.g. r120), thus even if a System Routine hang occurs, as much of the GRF is visible as possible. (Note that this would also require the System Routine to update the progress of the GRF dump, perhaps with each GRF block written, or to initialize the System Routine's scratch space to a known value, to be able to distinguish valid/locations from unwritten locations). Also a driver implementation may consider a disable-NoDDclr option in which jitted code does not use the NoDDClr capability. In this case, there is no change to the code that is jitted other than removal of the NoDDClr instruction option. The code executes as normal, but with a higher number of thread switches in what would have been a NoDDClr code block. 4.3 Exception Descriptions This section describes conditions that can cause exceptions and transfer control to the System Routine. 4.3.1 Illegal Opcode The ISA defines a single illegal opcode. The byte value of the illegal opcode is 0x00 due to it being a likely byte value encountered by a wayward instruction pointer value. The illegal instruction signals an exception if exception handling is enabled and invokes the system interrupt routine. If exception handling is NOT enabled, the illegal opcode is executed resulting in undetermined behavior including a system hang. Hardware decodes all legal opcodes supported. Any byte value that is not in the legal opcode list is decoded as an illegal opcode to trigger exception. 4.3.2 Undefined Opcodes All undefined opcodes in the 8-bit opcode space (which includes instruction bit 7, reserved for future opcode expansion) are detected by hardware. If an undefined opcode is detected, the opcode is overridden by hardware, forcing the opcode value within the pipeline to the defined illegal opcode. The offending instruction, should it eventually be issued down the execution unit’s pipeline, generates an Illegal Opcode exception as described in the section Illegal Opcode. The memory location of the offending opcode keeps its original value. That location can be queried to determine the opcode value. 4.3.3 Software Exception A mechanism is provided to allow an application thread to invoke an exception and is triggered using the Software Exception Set and Clear bit of cr0.1. Sub-function determination and parameter passing into and out of the exception handler is left to convention between the system-thread and application-thread. The thread's IP is incremented before saving AIP and entering the System Routine, causing execution to resume at the next application-thread instruction after returning from the System Routine. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 86 4.3.4 Context Save and Restore The System Routine is also used to save and restore the context of the Execution Unit. This feature is enabled in GPGPU workloads only. When the execution engine receives a preemption or an interrupt, the application thread invokes the System Routine. The System Routine is invoked only when all in-flight registers have retired. The system routine is used to save all the state of the EU to memory. When the sequence is complete, the master exception control bit is cleared. This action stops all execution for the given thread and invalidates the thread. This means a new thread from a different context may be loaded. When the master exception control bit is cleared, software must ensure that all outstanding messages from the EU are dispatched out of the execution message pipeline. This is achieved by creating a dependency on the last send that is saving EU state. A dummy instruction before clearing the master exception control bit ensures that this is achieved. The System Routine is also invoked on a context restore request. In this case a dummy thread is loaded into the EU which starts with the System Routine. This routine now restores the state of the EU. The restore sequence used in such a case should be consistent with the save sequence to ensure that state is restored correctly. After completing the restore sequence, the System Routine must clear the master exception control bit in the Control Register. This enables hardware to switch to the application thread which continues execution. 4.4 Events That Do Not Generate Exceptions The conditions described in this section are either not recognized or do not generate an exception. 4.4.1 Illegal Instruction Format This condition includes malformed instructions in which the opcode is legal, but the source or destination operands or other instruction attributes do not comply with the instruction specification. There is no direct hardware support to detect these cases and the outcome of issuing a malformed instruction is undefined. Note that GEN does not support self-modifying code, therefore the driver has an opportunity to detect such cases before the thread is placed in service. 4.4.2 Malformed Message A message's contents, destination registers, lengths, and descriptors are not interpreted in any way by the execution unit. Errors in specifying message fields do not raise exceptions in the EU but may be detected and reported by the shared functions . 4.4.3 GRF Register Out of Bounds Unique GRF storage is allocated to each thread which, at a minimum, satisfies the register requirements specified in the thread's declaration. References to GRF register numbers beyond that called for in the thread's declaration do not generate exceptions. Depending on the implementation, out-of-bounds register numbers may be remapped to r0..r15, although this functionality should not be relied upon by the thread. The hardware guarantees the isolation of each thread's register space, thus there is no possibility of direct register manipulation via an out-of-bounds register access. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 87 4.4.4 Hung Thread There is no hardware mechanism in the EU to detect a hung thread and such a thread may remain hung indefinitely. It is expected that one or more hung threads will eventually cause the driver to recognize a context timeout and take appropriate recovery action. 4.4.5 Instruction Fetch Out of Bounds The EU implements a full 32-bit instruction address range (with the 4 LSBs don’t care), making it possible for a thread to attempt to jump to any 16-byte aligned offset in the 32-bit instruction address range. (Instruction addresses are offsets from the General State Base Address.) The EU does not provide any type of address checking on instruction fetch requests sent to the memory/cache hierarchy, although error conditions for memory addresses are reported via the Page Table Error Register and other memory interface registers. 4.4.6 FPU Math Errors The EU's floating point units (FPUs) have defined behaviors for traditional floating point errors and do not generate exceptions. There is no support for signaling FPU math errors as exceptions. 4.4.7 Computational Overflow Depending on source operand types and values, destination type, and the operation being performed, overflows may occur in the execution pipelines. Many instructions support the overflow (.o) conditional modifier that assigns flag bits based on whether or not an overflow occurs. The EU never signals exceptions for overflows. Software must provide any overflow handling. 4.5 System Routine Example The following code sequence illustrates some concepts of the System Routine. It is intended to be just a shell, without getting into the specifics of each exception handler. This example contains code for the message registers in the MRF. All message register and MRF references are specific to DevSNB. Other code in this example is useful for other processor generations. The example frees enough MRF and GRF space to get the routine started, then jumps to the handler for the specific exception. Many other implementations are also valid, including single exception servicing (as opposed to looping) per invocation, and saving only the GRF or MRF space required by the exception being serviced. #define ACC_DISABLE_MASK 0xFFFFFFFD #define MASTER_EXCP_MASK 0x7FFFFFFF #define SYSROUTINE_SCRATCH_BLKSIZE 16384 // for example // Shared function IDs: #define DPR 0x04000000 #define DPW 0x05000000 // Message lengths: #define ML5 0x00500000 #define ML9 0x00900000 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 88 // Response lengths: #define RL0 0x00000000 #define RL4 0x00040000 #define RL8 0x00080000 // Data port block sizes: #define BS1_LOW 0x0000 #define BS1_HIGH 0x0100 #define BS2 0x0200 #define BS4 0x0300 // Scratch Layout: #define SCR_OFFSET_MRF 0 // MRF is specific to DevSNB. #define SCR_OFFSET_GRF 512 // + 16 MRF registers #define SCR_OFFSET_ARF 512 + 4096 // + 16 MRF + 128 GRF registers // Write data port constants: // target=dcache, type= oword_block_wr, binding_tbl_offset=0 #define DPW 0x000 // Read data port constants: // target=dcache, type= oword_block_rd, binding_tbl_offset=0 #define DPR 0x000 Sys_Entry: // Entry point to the System Routine. // Disable accumulator for system routine: and (1) cr0.0 cr0.0 ACC_DISABLE_MASK {NoMask} // Calc scratch offset for this thread into r0.4: shr (1) r0.4 sr0.0:uw 6 {NoMask} add (1) r0.4 r0.4 sr0.0:ub {NoMask} mul (1) r0.4 r0.4 SYSROUTINE_SCRATCH_BLKSIZE {NoMask} // Setup m0 with block offset: mov (8) m0 r0{NoMask} // Save MRF 7..0 (may choose to save the whole MRF). MRF is specific to DevSNB: add (1) m0.2 r0.4 SCR_OFFSET_MRF {NoMask} send (8) null m0 null DPW|ML9|RL0 {NoMask} // Save MRF 8..15 (optional; req’ed if sys-routine stays w/in mrf7-0). MRF is specific to DevSNB. mov (8) m7 r0 {NoMask} add (1) m7.2 r0.4 (SCR_OFFSET_MRF + 256) {NoMask} send (8) null m7 null DPW|ML9|RL0 {NoMask} // Save r0..r1 to system scratch: // Note: done as a single register to guarantee external visibility // See Use of NoDDClr mov (16) m1 r0 {NoMask} send (8) m0 null null DPW|ML2|RL0 {NoMask} // Save r2..r3 to free some room: mov (16) m3 r2 {NoMask} add (1) m0.2 r0.4 SCR_OFFSET_GRF + 64 {NoMask} send (8) m0 null null DPW|ML4|RL0 {NoMask} Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 89 // Save r4..r7 to free some room (optional, depending on needs): mov (16) m8 r4 {NoMask} mov (16) m10 r6 {NoMask} add (1) m7.2 r0.4 (SCR_OFFSET_GRF + 128) {NoMask} send (8) m7 null null DPW|ML5|RL0 {NoMask} // Save r8..r11 to free some room (optional, depending on needs): mov (16) m1 r8 {NoMask} mov (16) m3 r10 {NoMask} add (1) m0.2 r0.4 (SCR_OFFSET_GRF + 256) {NoMask} send (8) m0 null null DPW|ML5|RL0 {NoMask} // Save r12..r15 to free some room (optional, depending on needs): mov (16) m8 r12 {NoMask} mov (16) m10 r14 {NoMask} add (1) m7.2 r0.4 (SCR_OFFSET_GRF + 384) {NoMask} send (8) m7 null null DPW|ML5|RL0 {NoMask} // Save selected ARF registers (optional, depending on use): // flags, others ... // Save f0.0: mov (1) r1.0:uw f0.0 {NoMask} Next: // Exceptions pending? If not, exit. cmp.e (1) f0.0 cr0.4:uw 0:uw {NoMask} (f0.0) mov (1) IP EXIT {NoMask} // Find highest priority exception: lzd (1) r1.1:uw cr0.4:uw {NoMask} // Jump table to service routine: jmpi (1) r1.1:uw{NoMask} mov (1) IP CRService_0 {NoMask} mov (1) IP CRService_1 {NoMask} mov (1) IP CRService_2 {NoMask} ... mov (1) IP CRService_15{NoMask} mov (1) IP Next Service_0: // Clear exception from cr0.1. // Perform service routine. // Jump to exit (or if looping on exceptions, go to next loop). ... Service_15: // Clear exception from cr0.1. // Perform service routine. // Jump to exit (or if looping on exceptions, go to next loop). Exit: // Restore f0.0. // Restore other ARF registers (as required). // Restore r12..r15. // Restore r8..r11. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 90 // Restore r4..r7. // Restore r0..r3. // Restore m8..m15. // Restore m0..m7. // Clear Master Exception State bit in cr0.0: and (1) cr0.0 cr0.0 MASTER_EXCP_MASK nop (16) Below is a code sequence to programmatically clear the GRF scoreboard in case of a timeout waiting on a register that may never return. At this point, all we know is we have a hung thread. We’d like to copy the GRF to scratch memory to make it visible , but there may be a register that is hung with an outstanding dependency. To get around any hung dependency, walk the GRF using NoDDChk, using an execution mask of f0 == 0 so we don’t touch the register contents. Clear_Dep: mov f0 0x00 (f0) mov r0 0x00 {NoDDChk} (f0) mov r1 0x00 {NoDDChk} (f0) mov r2 0x00 {NoDDChk} ... (f0) mov r127 0x00 {NoDDChk} // GRF scoreboard now cleared. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 91 5. Instruction Set Summary 5.1 Instruction Set Characteristics 5.1.1 5nstruction Operands and Register Regions Most instructions may have up to three operands, two sources and one destination. Each operand is able to address a register region. Source operands support negate and absolute modifier and channel swizzle, and the destination operand supports channel mask. Dual destination instructions are also supported (four-operand instructions in a general sense): One case is for the implied destination – flag register, where the conditional modifiers and the predicate modifiers may apply. Another case is the message header creation (implied move or implied assembling of the header) in the send instruction. Each execution channel contains an accumulator that is wider than the input data to support back-to-back accumulation operations with increased precision. The added precision (see accumulator register description in Execution Environment chapter) determines the maximum number of accumulations before possible overflow. The accumulator can be pre-loaded through the use of mov. It can also be pre-loaded by arithmetic instructions such as add or mul, since the result of these instructions can go to the accumulator. The accumulator registers are per thread and therefore safe for thread switching. Register access can be direct or register-indirect. Register-indirect register access uses address registers plus an immediate offset term to compute the register addresses, and only applies to the first source operand (src0) and/or the destination operand. There is one address register. There are 8 address sub-registers.Each sub-register contains a 16-bit unsigned value. The leading two sub-registers form a special doubleword that can be used as the descriptor for the send instruction. Source operand can also be immediate value (also referred to as inline constants). For instructions with two source operands, only the second operand src1 is allowed to be immediate. For instructions with only one source operand, the source operand src0 is used and it can be an immediate. An immediate source operand can be a scalar value of specified type up to 32-bit wide, which is replicated to create a vector with length of Execution Size. An immediate operand can also be a special 32-bit vector with 8 elements each of 4-bit signed integer value, or a 32-bit vector with 4 elements each of 8-bit restricted float value. 5.1.2 Instruction Execution It is implied that all instructions operate across all channels of data unless otherwise specified either via destination mask, predication, execution mask (caused by SIMD branch and loop instructions), or execution size. Instruction execution size can be specified per instruction, from scalar (ExecSize = 1) up to the maximal execution size supported for the data type, with the restriction that execution size can only be in power of 2. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 92 5.2 Instruction Machine Formats This section shows the machine formats of the instruction set. The instructions in the architecture have a fixed length of 128 bits in the native format. A compact format, discussed separately in this volume, can represent some instructions using 64 bits. Out of the 128 bits in the native format, there are 120 bits in use, and the remaining bits are reserved for future extensions. One instruction consists of instruction fields that control various stages of execution. These fields are roughly grouped into the 4 DWords as follows:  Instruction Operation Doubleword (DW0) contains the Opcode and other general instruction control fields.  Instruction Destination Doubleword (DW1) specifies the destination operand (dst) and the register file and type of source operands.  Instruction Source 0 Doubleword (DW2) contains the first source operand (src0).  Instruction Source 1 Doubleword (DW3) contains the second source operand (src1) and is used to hold any 32-bit immediate source (imm32 as src0 or src1). Most instructions have 1 or 2 source operands and use a common instruction format. Within that format, there are variations based on AddrMode and AccessMode. There is a separate instruction format for a small number of instructions with 3 source operands. Send, math, and branching instructions have format variations described separately. The 3-source instructions have the following restrictions:  Only GRF registers can be sources, and only GRF registers can be the destination.  Subregister numbers have DWord granularity.  AccessMode is Align16, uses Align16-style swizzling, with extra replication control. There is no other regioning support. The next two subsections describe the instruction formats for various processor generations using tables. The following diagrams provide another view of the same information. The first two diagrams are for native instructions with one or two source operands. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 93 Instruction Format – 1-src and 2-src The next two diagrams are for instructions with three source operands. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 94 Instruction Format – 3-src Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 95 5.2.1 EU Instruction Formats This section covers the layout of instruction fields, not changes in allowed field encodings from generation to generation. For example, adds new data types and instructions which add new allowed values for particular fields, but those changes do not change field positions or layout. DWord 0, bits 31:0 of the 128-bit instruction, has the same format regardless of the number of source operands. The following three tables cover the most common instruction format, for instructions with 1 or 2 source operands; then the format for the few instructions with 3 source operands; and finally format variations used by a few exceptional instructions. Execution Unit Instruction Format for 1 or 2 Source Operands AddrMode and AccessMode Variations AddrMode = Direct AddrMode = Indirect Bits Description Align16 Align1 Align16 Align1 Any Imm32 32-bit immediate operand uses bits 127:96, replacing the following fields. 127:121 Reserved 120:117 Src1.VertStride 116 Varies based on AccessMode Reserved Src1.Width Reserved Src1.Width 115:114 Src1.ChanSel[7:4] Src1.ChanSel[7:4] 113:112 Src1.HorzStride 111 Src1.AddrMode 110:109 Src1.SrcMod 108:106 Varies based on AddrMode and Src1.RegNum Src1.AddrSubRegNum 105:101 AccessMode Src1.AddrImm[9:4] Src1.AddrImm[9:0] 100 99:96 Src1.ChanSel[3:0] Src1.ChanSel[3:0] 95:91 Reserved 90 FlagRegNum 89 FlagSubRegNum 88:85 Src0.VertStride 84 Varies based on AccessMode Reserved Src0.Width Reserved Src0.Width 83:82 Src0.ChanSel[7:4] Src0.ChanSel[7:4] 81:80 Src0.HorzStride 79 Src0.AddrMode 78:77 Src0.SrcMod 76:74 Varies based on AddrMode and Src0.RegNum Src0.AddrSubRegNum 73:69 AccessMode Src0.AddrImm[9:4] Src0.AddrImm[9:0] 68 67:64 Src0.ChanSel[3:0] Src0.ChanSel[3:0] 63 Dst.AddrMode 62:61 Varies based on AccessMode Reserved Dst.HorzStride Reserved Dst.HorzStride 60:58 Varies based on AddrMode and Dst.RegNum Dst.AddrSubRegNum 57:53 AccessMode Dst.AddrImm[9:4] Dst.AddrImm[9:0] 52 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 96 AddrMode and AccessMode Variations AddrMode = Direct AddrMode = Indirect Bits Description Align16 Align1 Align16 Align1 51:48 Dst.ChanEn[3:0] Dst.ChanEn[3:0] 47 NibCtrl 46:44 Src1.SrcType 43:42 Src1.RegFile 41:39 Src0.SrcType 38:37 Src0.RegFile 36:34 Dst.DstType 33:32 Dst.RegFile 31 Saturate 29 CmptCtrl 28 AccWrCtrl 27:24 CondModifier 23:21 ExecSize 20 PredInv 19:16 PredCtrl 15:14 ThreadCtrl 13:12 QtrCtrl 11:10 DepCtrl 9 MaskCtrl 8 AccessMode 7 Reserved (for future Opcode expansion) 6:0 Opcode The 3-source operand instructions are: bfe - Bit Field Extract bfi2 - Bit Field Insert 2 lrp - Linear Interpolation mad - Multiply Add In the 3-source instruction format, the upper QWord contains three groups of 21 bits for the three source operands, where each group contains four fields in 20 bits and otherwise adjacent groups are separated by single reserved bits. Execution Unit Instruction Format for 3 Source Operands Bits Description 127:126 Reserved 125:118 Src2.RegNum 117:115 Src2.SubRegNum 114:107 Src2.ChanSel 106 Src2.RepCtrl 105 Reserved 104:97 Src1.RegNum 96 Src1.SubRegNum[2] 95:94 Src1.SubRegNum[1:0] 93:86 Src1.ChanSel 85 Src1.RepCtrl 84 Reserved Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 97 Bits Description 83:76 Src0.RegNum 75:73 Src0.SubRegNum 72:65 Src0.ChanSel 64 Src0.RepCtrl 63:56 Dst.RegNum 55:53 Dst.SubRegNum 52:49 Dst.ChanEnable 48 Reserved 47 NibCtrl 46 Reserved 45:44 DstType 43:42 SrcType 41:40 Src2.Modifier 39:38 Src1.Modifier 37:36 Src0.Modifier 35 Reserved 34 FlagRegNum 33 FlagSubRegNum 32 Reserved 31 Saturate 29 CmptCtrl 28 AccWrCtrl 27:24 CondModifier 23:21 ExecSize 20 PredInv 19:16 PredCtrl 15:14 ThreadCtrl 13:12 QtrCtrl 11:10 DepCtrl 9 MaskCtrl 8 AccessMode 7 Reserved (for future Opcode expansion) 6:0 Opcode Specific instructions have different instruction formats as described below. These instructions include send / sendc, math, and branch instructions. Execution Unit Instruction Format for Specific Instructions Regular 1 or 2 Empty white areas mean Same, use the regular description Source Operands Branch Bits Description send / sendc math Instructions 127 Reserved EOT UIP[15:0] 126:125 (2-offset 124:121 Imm[28:0] / branches) 120:117 Reg32 Src1.VertStride 116:112 Varies based on Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 98 Regular 1 or 2 Empty white areas mean Same, use the regular description Source Operands Branch Bits Description send / sendc math Instructions AccessMode 111 Src1.AddrMode JIP[15:0] 110:109 Src1.SrcMod 108:96 Varies based on AddrMode and AccessMode 95:91 Reserved 90 FlagRegNum 89 FlagSubRegNum 88:85 Src0.VertStride 84:80 Varies based on AccessMode 79 Src0.AddrMode 78:77 Src0.SrcMod 76:64 Varies based on AddrMode and AccessMode 63 Dst.AddrMode Any branch instruction: 62:61 Varies based on AccessMode Same as regular 60:48 Varies based on AddrMode and AccessMode 47 NibCtrl 46:44 Src1.SrcType 43:42 Src1.RegFile 41:39 Src0.SrcType 38:37 Src0.RegFile 36:34 Dst.DstType 33:32 Dst.RegFile 31 Saturate 29 CmptCtrl 28 AccWrCtrl 27:24 CondModifier SFID[3:0] FC[3:0] Any branch instruction: MBZ 23:21 ExecSize 20 PredInv 19:16 PredCtrl 15:14 ThreadCtrl 13:12 QtrCtrl 11:10 DepCtrl 9 MaskCtrl 8 AccessMode 7 Reserved (for future Opcode expansion) 6:0 Opcode Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 99 5.2.2 Common Instruction Fields As shown in the table below, the meanings (encoding) of certain bit fields in the 128-bit native instruction format varies depending on the values of other bit fields. Common Instruction Fields provides the definition of common fields in the native instruction format. The ‘Width’ column specifies the width of the field in bits. These common fields are referenced in describing the fields of different doublewords of the instruction. The definition for fields that have unique representations can be found in the sections for the corresponding instruction DWords. Definitions of Common Instruction Fields Field Description Width 4 CondModifier Conditional Modifier. This field sets the flag register based on the internal conditional signals output from the execution pipe such as sign, zero, overflow and NaNs, etc. If this field is set to 0000, no flag registers are updated. Flag registers are not updated for instructions with embedded compares. This field applies to all instructions except send, sendc, and math. 0000 = Do not modify the flag register (normal) 0001 = Zero or Equal (.z or .e) 0010 = Not Zero or Not Equal (.nz or .ne) 0011 = Greater-than (.g) 0100 = Greater-than-or-equal (.ge) 0101 = Less-than (.l) 0110 = Less-than-or-equal (.le) 0111 = Reserved 1000 = Overflow (signed overflow) (.o) 1001 = Unordered with Computed NaN (.u) 1010 -1111 = Reserved 1 AddrMode Addressing Mode. This field determines the addressing method of the operand. Normally the destination operand and each source operand each have a distinct addressing mode field. When it is cleared, the register address of the operand is directly provided by bits in the instruction word. It is called a direct register addressing mode. When it is set, the register address of the operand is computed based on the address register value and an address immediate field in the instruction word. This is referred to as a register-indirect register addressing mode. This field applies to the destination operand and the first source operand, src0. Support for src1 is device dependent. See Table XX (Indirect source addressing support available in device hardware) in ISA Execution Environment for details. 0 = “Direct”. Direct register addressing 1 = “Register-Indirect” (or in short “Indirect”). Register-indirect register addressing 8 RegNum Register Number. This field provides the register number for the operand. For GRF register operand, it provides the portion of register address aligning to 256-bit. For an ARF register operand, this field is encoded such that MSBs identify the architecture register type Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 100 Field Description Width and LSBs provide its register number. This field together with the corresponding SubRegNum field provides the byte aligned address for the origin of the register region. Specifically, this field provides bits [12:5] of the byte address, while SubRegNum field provides bits [4:0]. This field applies to the destination operand and the source operands. It is ignored (or not present in the instruction word) for an immediate source operand. This field is present if the operand is in direct addressing mode; it is not present if the operand is register-indirect addressed. Format = U8, if RegFile = GRF. 0x00 to 0x7F = Register number in the range of [0, 127] 0x80 to 0xFF = Reserved 0x00 to 0x0F = Register number in the range of [0, 15] 0x10 to 0xFF = Reserved Format = 8-bit encoding, if RegFile = ARF. This field is used to encode the architecture register as well as providing the register number. See GEN Execution Environment chapter for details. 5 SubRegNum Sub-Register Number. This field provides the sub-register number for the operand. For a GRF register operand, it provides the byte address within a 256-bit register. For an ARF register operand, this field also provides the sub-register number according to the encoding defined for the given architecture register. This field together with the corresponding RegNum field provides the byte aligned address for the origin of the register region. Specifically, this field provides bits [4:0] of the byte address, while the RegNum field provides bits [12:5]. This field applies to the destination operand and the source operands. It is ignored (or not present in the instruction word) for an immediate source operand. This field is present if the operand is in direct addressing mode; it is not present if the operand is register-indirect addressed. Note: The recommended instruction syntax uses subregister numbers within the GRF in units of actual data element size, corresponding to the data type used. For example for the F (Float) type, the assembler syntax uses subregister numbers 0 to 7, corresponding to subregister byte addresses of 0 to 28 in steps of 4, the element size. Format = U5, if RegFile = GRF 0x00 to 0x1F = Sub-Register number in the range of [0, 31] Format = 5-bit encoding, if RegFile = ARF. This field is used to encode the architecture register as well as providing the register number. See GEN Execution Environment chapter for details. 3 AddrSubRegNum Address Sub-Register Number. This field provides the subregister number for the address register. The address register contains 8 sub-registers. The size of each subregister is one word. The address register contains the register address of the operand, when the operand is in register-indirect addressing mode. This field applies to the destination operand and the source operands. It is ignored (or not present in the instruction word) for an immediate source operand. This field is present if the operand is in register-indirect addressing mode; it is not present if Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 101 Field Description Width the operand is directly addressed. An address subregister used for indirect addressing is often called an index register. Format = U3 0x0 to 0x7 = Address Sub-Register number in the range [0, 7] 10 AddrImm Address Immediate. This field provides the immediate value in units of bytes added to the address register to compute the register address (byte-aligned region origin) for the operand. It is a signed integer. This field is present if the operand is in register-indirect addressing mode; it is not present if the operand is directly addressed. Note: that the address immediate field may not be able to cover the whole GRF register range for a thread, as the maximum GRF register space for a thread is 4KB. Format = S9 Valid range: [-512, 511] 2 SrcMod Source Modifier. This field specifies the numeric modification of a source operand. The value of each data element of a source operand can optionally have its absolute value taken and/or its sign inverted prior to delivery to the execution pipe. The absolute value is prior to negate such that a guaranteed negative value can be produced. This field only applies to source operand. It does not apply to destination. This field is not present for an immediate source operand. 00 = No modification (normal) 01 = “(abs)”. Absolute 10 = “–”. Negate 11 = “–(abs)”. Negate of the absolute (forced negative value) 4 VertStride Vertical Stride. The field provides the vertical stride of the register region in unit of data elements for an operand. Encoding of this field provides values of 0 or powers of 2, ranging from 1 to 32 elements. Larger values are not supported due to the restriction that a source operand must reside within two adjacent 256-bit registers (64 bytes total). Special encoding 1111b (0xF) is only valid when the operand is in register-indirect addressing mode (AddrMode = 1). If this field is set to 0xF, one or more sub-registers of the address registers may be used to compute the addresses. Each address sub-register provides the origin for a row of data element. The number of address sub-registers used is determined by the division of ExecSize of the instruction by the Width fields of the operand. This field only applies to source operand. It does not apply to destination. This field is not present for an immediate source operand. Note 1: Vertical Stride larger than 32 is not allowed due to the restriction that a source operand must reside within two adjacent 256-bit registers (64 bytes total). Note 2: In Align16 access mode, as encoding 0xF is reserved, only single-index indirect addressing is supported. Note 3: If indirect address is supported for src1, encoding 0xF is reserved for src1 – only single-index indirect addressing is supported. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 102 Field Description Width 0000 = 0 Elements 0001 = 1 Element 0010 = 2 Elements 0011 = 4 Elements 0100 = 8 Elements 0101 = 16 Elements (applies to byte or word operand only) 0110 = 32 Elements (applies to byte operand only) 0111-1110 = Reserved 1111 = VxH or Vx1 mode (only valid for register-indirect addressing in Align1 mode) 3 Width Width. This field specifies the number of elements in the horizontal dimension of the region for a source operand. This field cannot exceed the ExecSize field of the instruction. This field only applies to source operand. It does not apply to destination. This field is not present for an immediate source operand. 000 = 1 Elements 001 = 2 Elements 010 = 4 Elements 011 = 8 Elements 100 = 16 Elements 101-111 = Reserved 2 HorzStride Horizontal Stride. This field provides the distance in unit of data elements between two adjacent data elements within a row (horizontal) in the register region for the operand. This field applies to both destination and source operands. This field is not present for an immediate source operand. 00 = 0 Elements 01 = 1 Element 10 = 2 Elements 11 = 4 Elements 32 Imm32 32-bit Immediate. The 32-bit immediate data field for the operand. It may contain any legal bit pattern for its associated type. Only one 32-bit immediate value may be present in an instruction, therefore binary operations only support src1 as an immediate value. The low order bits are directly used when fewer than 32-bits are needed to describe the desired type; the 32-bits are not coerced into the designated type. For UW and W data types, programmer is required to replicate the lower word to the upper word of this field. This field only applies to the last source operand. Signed and unsigned byte integer data types are not supported for an immediate operand. See the Numeric Data Types section for information about data types and their ranges. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 103 Field Description Width 4 ChanEn Channel Enable. Four channel enables are defined for controlling which channels will be written into the destination region. These channel mask bits are applied in a modulo-four manner to all ExecSize channels. There is 1-bit Channel Enable for each channel within the group of 4. If the bit is cleared, the write for the corresponding channel is disabled. If the bit is set, the write is enabled. Mnemonic for the bit being set for the group of 4 is “x”, “y”, “z”, and “w”, respectively, where “x” corresponds to Channel 0 in the group and “w” corresponds to channel 3 in the group. This field only applies to destination operand. This field is only present in Align16 mode. 0 = Write Disabled 1 = Write Enabled (normal) 8 ChanSel Channel Select. This field controls the channel swizzle for a source operand. The normally sequential channel assignment can be altered by explicitly identifying neighboring data elements for each channel. Out of the 8-bit field, 2 bits are assigned for each channel within the group of 4. ChanSel[1:0], [3.2], [5.4] and [7,6] are for channel 0 (“x”), 1 (“y”), 2 (“z”), and 3 (“w”) in the group, respectively. For example with an execution size of 8, r0.0<4>.zywz:f would assign the channels as follows: Chan0 = Data2, Chan1 = Data1, Chan2 = Data3, Chan3 = Data2; Chan4 = Data6, Chan5 = Data5, Chan6 = Data7, Chan7 = Data6. This field only applies to source operand. This field is only present in Align16 mode. It is not present for an immediate source operand. The 2-bit Channel Selection field for each channel within the group of 4 is defined as the following. 00 = “x”. Channel 0 is selected for the corresponding execution channel 01 = “y”. Channel 1 is selected for the corresponding execution channel 10 = “z”. Channel 2 is selected for the corresponding execution channel 11 = “w”. Channel 3 is selected for the corresponding execution channel 1 RepCtrl Replicate Control. This field controls the replication of the starting channel to all channels in the execution size. This field applies to all three source operands. 0 = No replication 1 = Replicate across all channels [Errata Astep] Replicate Control is not supported. As a WorkAround, Break 3 source instructions to simd4 and use channel select when replicate control is required. 31 MsgDscpt31 Message Description. This field, containing 31-bit immediate values, provides the description of the message to be sent. This field only applies to the send instruction. It is not present for other instructions. The meaning of the field depends on the type of message as well as the message shared function target. Format: U31 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 104 Field Description Width 1 EOT End of Thread. This field controls the termination of the thread. For a send instruction, if this field is set, EU will terminate the thread and also set the EOT bit in the message sideband. This field only applies to the send instruction. It is not present for other instructions. 0 = The thread is not terminated 1 = EOT 5.2.3 Instruction Operation Doubleword (DW0) Most fields in Instruction Operation Doubleword (DW0) apply to all instructions. Bit field [27:24] is one exception. It is CondModifier for most instructions but is SFID[3:0] field for the send instruction. The descriptions in the table below are shared between the 1-src/2-src instructions and 3-src instructions. Definitions of Fields in Operation Doubleword (DW0) Bits Description 31 Saturate. This field controls the destination saturation. When it is set, output data to the destination register are saturated. The saturation operation depends on the destination data type. Saturation is the operation that converts any data that is outside the saturation target range for the data type to the closest represented value with the target range. If destination type is float, saturation target range is [0, 1]. For example, any positive number greater than 1 (including +INF) is saturated to 1 and any negative number (including –INF) is saturated to 0. A NaN is saturated to 0, For integer data types, the maximum range for the given numeric data type is the saturation target range. When it is not set, output data to the destination register are not saturated. For example, a wrapped result (modular) is output to the destination for an overflowed integer data. More details can be found in the Data Types chapter. 0 = No destination modification (normal) 1 = “sat”. Saturate the output Destination Saturation Target Range Type (inclusive) Float (F) [0.0, 1.0] Byte (UB) [0, 255] Signed Byte (B) [-128, 127] Word (UW) [0, 65535] Signed Word (W) [-32768, 32767] Double Word [0, 232-1] (UD) Signed Double [-231, 231-1] (D) Reserved: MBZ 29 28 AccWrCtrl. This field allows per instruction accumulator write control. 0 = don’t write result into accumulator 1 = “AccWrCtrl”. write result into accumulator, and destination Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 105 Bits Description 27:24 CondModifier or CurrDst.RegNum[3:0] Definition of this bit field depends on whether the instruction is a send/math or not. Opcode != ‘send’ Opcode = ‘send’ CondModifier: CurrDst.RegNum[3:0] This field sets the This field sets the MRF register flag register based number for the current on the internal destination operand in the send conditional signals instruction. No flag registers are output from the updated for the send instruction. execution pipe. The 4-bit field provides full access of the 16 MRF registers. (See Instruction Reference chapter for CurrDst.) 23:21 ExecSize – Execution Size. This field determines the number of channels operating in parallel for this instruction. The size cannot exceed the maximum number of channels allowed for the given data type. 000b = 1 channel (scalar operation) 001b = 2 channels 010b = 4 channels 011b = 8 channels 100b = 16 channels 101 = 32 channels 110-111 = Reserved 20 PredInv – Predicate Inverse. This field, together with PredCtrl, enables and controls the generation of the predication mask for the instruction. When it is set, the predication uses the inverse of the predication bits generated according to setting of Predicate Control. In other words, effect of PredInv happens after PredCtrl. This field is ignored by hardware if Predicate Control is set to 0000 – there is no predication. 0 = “+”. Positive polarity of predication. 1 = “–”. Negative polarity of predication. 19:16 PredCtrl – Predicate Control. This field, together with PredInv, enables and controls the generation of the predication mask for the instruction. It allows per-channel conditional execution of the instruction based on the content of the selected flag register. Encoding depends on the access mode. In Align16 access mode, there are eight encodings (including no predication). All encodings are based on group-of-4 predicate bits, including channel sequential, replication swizzles and horizontal any|all operations. The same configuration is repeated for each group-of-4 execution channels. See the Predication section for more informatio about predication. In Align1 access mode, there are twelve encodings (including no predication). The encodings applies to all execution channels with explicit channel grouping from single channel up to group of 16 channels. Predicate Control in Align16 access mode 0000 = No predication (normal) Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 106 Bits Description 0001 = Predication with sequential flag channel mapping 0010 = Predication with replication swizzle ‘.x’ 0011 = Predication with replication swizzle ‘.y’ 0100 = Predication with replication swizzle ‘.z’ 0101 = Predication with replication swizzle ‘.w’ 0110 = Predication with ‘.any4h’ 0111 = Predication with ‘.all4h’ 1000 -1111 = Reserved Predicate Control in Align1 access mode 0000 = No predication (normal) 0001 = Predication with sequential flag channel mapping 0010 = Predication with .anyv (any from f0.0-f0.1 on the same channel) 0011 = Predication with .allv (all of f0.0-f0.1 on the same channel) 0100 = Predication with .any2h (any in group of 2 channels) 0101 = Predication with .all2h (all in group of 2 channels) 0110 = Predication with .any4h (any in group of 4 channels) 0111 = Predication with .all4h (all in group of 4 channels) 1000 = Predication with .any8h (any in group of 8 channels) 1001 = Predication with .all8h (all in group of 8 channels) 1010 = Predication with .any16h (any in group of 16 channels) 1011 = Predication with .all16h (all in group of 16 channels) 1100 = Predication with .any32h (any in group of 32 channels) 1101 = Predication with .all32h (all in group of 32 channels) 1110 -1111 = Reserved 15:14 ThreadCtrl – Thread Control. This field provides explicit control for thread switching. If this field is set to 00b, it is up to the GEN execution units to manage thread switching. This is the normal (and unnamed) mode. In this mode, for example, if the current instruction cannot proceed due to operand dependencies, the EU switches to the next available thread to fill the compute pipe. In another example, if the current instruction is ready to go, however, there is another thread with higher priority that also has an instruction ready, the EU switches to that thread. If this field is set to Switch, a forced thread switch occurs after the current instruction is executed and before the next instruction. In addition, a long delay (longer than the execution pipe latency) is introduced for the current thread. Particularly, the instruction queue of the current thread is flushed after the current instruction is dispatched for execution. Switch is designed primarily as a safety feature in case there are race conditions for certain instructions. If this field is set to Atomic, the next instruction gets highest priority in thread arbitration for the execution pipeline. 00b = Normal thread control 10b = “Switch” Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 107 Bits Description 01b = “Atomic” 11b = Reserved 13:12 QtrCtrl – Quarter Control. This field provides explicit control for ARF selection. This filed combines with ExecSize determines which channels are used for the ARF registers. Along with NibCtrl in DW1, 1/8 DMask/VMask and ARF can be selected. QtrCtrl NibCtrl ExecSize Description BNF 00 x 8 use first quarter for 1Q DMask/VMask use first half for everything else 01 x 8 use second 2Q quarter for DMask/VMask use second half for everything else 10 x 8 use third quarter 3Q for DMask/VMask use first half for everything else 11 x 8 use forth quarter 4Q for DMask/VMask use second half for everything else 0x x 16 use first half for 1H DMask/VMask use all channels for everything else 1x x 16 use second half 2H for DMask/VMask use all channels for everything else 00 0 4 use first 1/8 for 1N DMask/VMask and ARF 00 1 4 use second 1/8 for 2N DMask/VMask and ARF 01 0 4 use third 1/8 for 3N DMask/VMask and ARF Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 108 Bits Description 01 1 4 use fourth 1/8 for 4N DMask/VMask and ARF 10 0 4 use fifth 1/8 for 5N DMask/VMask and ARF 10 1 4 use sixth 1/8 for 6N DMask/VMask and ARF 11 0 4 use seventh 1/8 for 7N DMask/VMask and ARF 11 1 4 use eighth 1/8 for 8N DMask/VMask and ARF 2H is only allowed for SIMD16 instruction in Single Program Flow mode (SPF=1). NibCtrl is only allowed for SIMD4 instructions with (DF) double precision source and/or destination. 11:10 DepCtrl – Destination Dependency Control. This field selectively disables destination dependency check and clear for this instruction. When it is set to 00, normal destination dependency control is performed for the instruction – hardware checks for destination hazards to ensure data integrity. Specifically, destination register dependency check is conducted before the instruction is made ready for execution. After the instruction is executed, the destination register scoreboard will be cleared when the destination operands retire. When bit 10 is set (NoDDClr), the destination register scoreboard will NOT be cleared when the destination operands retire. When bit 11 is set (NoDDChk), hardware does not check for destination register dependency before the instruction is made ready for execution. NoDDClr and NoDDChk are not mutual exclusive. When this field is not all-zero, hardware does not protect against destination hazards for the instruction. This is typically used to assemble data in a fine grained fashion (e.g. matrix-vector compute with dot-product instructions), where the data integrity is guaranteed by software based on the intended usage of instruction sequences. 00 = Destination dependency checked and cleared (normal) 01 = “NoDDClr”. Destination dependency checked but not cleared 10 = “NoDDChk”. Destination dependency not checked but cleared 11 = “NoDDClr, NoDDChk”. Destination dependency not checked and not cleared 9 MaskCtrl – Mask Control (formerly Write Enable Control). This field determines if the per channel write enables are used to generate the final write enable. This field should be normally “0”. 0 = use normal write enables (normal) 1 = write all channels, except channels killed with predication control. ChanEn is ignored in this case. MaskCtrl = NoMask skips the check for PcIP[n] == ExIP before enabling a channel, as described in the Evaluate Write Enable section. 8 AccessMode – Access Mode. This field determines the operand access for the instruction. It applies to all source and destination operands. When it is cleared (Align1), the instruction uses byte-aligned addressing for source and destination operands. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 109 Bits Description Source swizzle control and destination mask control are not supported. When it is set (Align16), the instruction uses 16-byte-aligned addressing for all source and destination operands. Source swizzle control and destination mask control are supported in this mode. 0 = “Align1” 1 = “Align16” Reserved: MBZ (for future opcode extension) 7 6:0 Opcode – Instruction Operation Code. This field contains the instruction operation code. Each opcode is given a unique mnemonic. For example, opcode 0x01 is for a move operation. Mnemonic for this opcode is mov. 5.2.4 Instruction Destination Doubleword (DW1) 5.2.4.1 DW1 1-src and 2-src Instructions Destination Doubleword (DW1) contains the register file and numeric type of all operands, as well as the register region parameters of the destination operand. See the Region Parameters section and the sections following it for more information about those parameters. Instruction Destination Doubleword Bits Description 31:16 Destination Register Region. This word contains the parameters describing the register region of the destination operand. Subfield definition depends on the AccessMode. See the Region Parameters section and the sections following it for more information about these parameters. Programming Notes: Allthough Dst.HorzStride is a don’t care for Align16, HW needs this to be programmed as “01”. Reserved: MBZ 15 14:12 Src1.SrcType – Source 1 Data Type. This field specifies the numeric data type of the source operand src1. The bits of a source operand are interpreted as the identified numeric data type, rather than coerced into a type implied by the operator. Depending on RegFile field of the source operand, there are two different encoding for this field. If a source is a register operand, this field follows the Source Register Type Encoding. If a source is an immediate operand, this field follows the Source Immediate Type Encoding. Source Register Type Encoding is identical to that for Destination Type. Source Immediate Type Encoding differs in two areas. First, it does not support byte and unsigned numeric data types. Second, it has three packed vector types, the V, UV, and VF types. Implementation Note 1: Both source operands, src0 and src1, support immediate types, but only one immediate is allowed for a given instruction and it must be the last operand. Implementation Note 2: Halfbyte integer vector (v) type can only be used in instructions in packed-word execution mode. Therefore, in a two-source instruction where src1 is of type :v, src0 must be of type :b, :ub, :w, or :uw. Source Register Type Encoding Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 110 Bits Description 000 = “UD”. Unsigned Doubleword integer 001 = “D”. Signed Doubleword integer 010 = “UW”. Unsigned Word integer 011 = “W”. Signed Word integer 100 = “UB”. Unsigned Byte integer 101 = “B”. Signed Byte integer 110 = Reserved 110 = “DF”. Double precision Float (64-bit) 111 = “F”. Single precision Float (32-bit) Source Immediate Type Encoding: 000 = “UD” 001 = “D” 010 = “UW” 011 = “W” 100 = “UV”. 32-bit halfbyte Unsigned Integer Vector 101 = “VF”. 32-bit restricted Vector Float 110 = “V”. 32-bit halfbyte integer Vector 111 = “F” 11:10 Src1.RegFile – Source 1 Register File. This field identifies the register file of source operand src1. 00 = “ARF”. Architecture Register File (a#, acc#, f#, n#, null, ip, etc.) 01 =“GRF”. General Register File (r#) 10 = “MRF”. Message Register File (m#) 10 = Reserved. Reserved. Do not use this encoding. 11 = “IMM”. Immediate 9:7 Src0.SrcType – Source 0 Data Type. This field is the SrcType for src0 operand. It has the same definitions as Src1.SrcType. 6:5 Src0.RegFile – Source 0 Register File. This field is the RegFile for src0 operand. It has the same definitions as Src1.RegFile. 4:2 Dst.DstType – Destination Data Type. This field specifies the numeric data type of the destination operand dst. The bits of the destination operand are interpreted as the identified numeric data type, rather than coerced into a type implied by the operator. For a send instruction, this field applies to the CurrDst – the current destination operand. Encoding: 000 = “UD”. Unsigned Doubleword integer 001 = “D”. Signed Doubleword integer 010 = “UW”. Unsigned Word integer Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 111 Bits Description 011 = “W”. Signed Word integer 100 = “UB”. Unsigned Byte integer 101 = “B”. Signed Byte integer 110 = Reserved 110 = ["DF"] Double Precision Float (64-bit) 111 = “F”. Single precision Float (32-bit) 1:0 Dst.RegFile – Destination Register File. This field identifies the register file of the destination operand dst. Note that it is obvious that immediate cannot be a destination operand. For a send instruction, this field applies to the PostDst – the post destination operand. Encoding: 00 = “ARF”. Architecture Register File (a#, acc#, f#, n#, null, ip, etc.) 01 =“GRF”. General Register File (r#) 10 = “MRF”. Message Register File (m#) 10 = Reserved. Reserved. Do not use this encoding. 11 = reserved The following tables describe the Destination Register Region based on the access mode and addressing mode. Destination Register Region in Direct + Align16 mode Bits Description 15 Dst.AddrMode – Destination Address Mode. This field is the AddrMode for the destination operand. For a send instruction, this field applies to PostDst – the post destination operand. Addressing mode for CurrDst (current destination operand) is fixed as Direct. (See Instruction Reference chapter for CurrDst and PostDst.) Reserved: MBZ 14:13 12:5 Dst.RegNum – Destination Register Number. This field is the RegNum field for the destination operand. For a send instruction, this field applies to PostDst. 4 Dst.SubRegNum[4]. This is the 16-byte aligned sub-register address. For a send instruction, this field applies to CurrDst. 3:0 Dst.ChanEn – Destination Channel Enable. The channel enable field for the destination operand. For a send instruction, this field applies to the CurrDst. Destination Register Region in Direct+Align1 mode Bits Description 15 Dst.AddrMode – Destination Address Mode. This field is the AddrMode for the destination operand. For a send instruction, it applies to PostDst. Addressing mode for CurrDst is fixed as Direct. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 112 Bits Description 14:13 Dst.HorzStride – Destination Horizontal Stride. This field is the HorzStride for the destination operand. For a send instruction, this field applies to CurrDst. PostDst only uses the register number. 12:5 Dst.RegNum – Destination Register Number. This field is the RegNum field for the destination operand. For a send instruction, this field applies to PostDst. 4:0 Dst.SubRegNum – Destination Sub-Register Number. This field is the SubRegNum for the destination operand.) Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. For a send instruction, this field applies to CurrDst. Destination Register Region in Indirect+Align16 mode Bits Description 15 Dst.AddrMode – Destination Address Mode. This field is the AddrMode for the destination operand. For a send instruction, this field applies to PostDst. Addressing mode for CurrDst is fixed as Direct. Reserved: MBZ 14:13 12:10 Dst.AddrSubRegNum – Destination Address Sub-Register Number. This field is the AddrSubRegNum for the destination operand. For a send instruction, this field applies to PostDst. 9:4 Dst.AddrImm[9:4] This is the half-register aligned AddrImm field for the destination operand. For a send instruction, this field applies to PostDst. 3:0 Dst.ChanEn – Destination Channel Enable. The channel enable field for the destination operand. For a send instruction, this field applies to the CurrDst. Destination Register Region in Indirect+Align1 mode Bits Description 15 Dst.AddrMode – Destination Address Mode. This field is the AddrMode for the destination operand. For a send instruction, this field applies to PostDst. Addressing mode for CurrDst is fixed as Direct. 14:13 Dst.HorzStride – Destination Horizontal Stride This field is the HorzStride for the destination operand. For a send instruction, this field applies to CurrDst. PostDst only uses the register number. 12:10 Dst.AddrSubRegNum – Destination Address Sub-Register Number. This field is the AddrSubRegNum for the destination operand. For a send instruction, this field applies to PostDst. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 113 Bits Description 9:0 Dst.AddrImm – Destination Address Immediate. This field is the byte-aligned AddrImm for the destination operand. For a send instruction, this field applies to PostDst. 5.2.4.2 DW1 3-src Instructions This section describes the field in DW1 for the 3-src instruction format. Instruction DW1 Bits Description 31:24 Destination Register Number. This field contains the destination register number. 23:21 Destination Subregister Number. This field contains the destination subregister number. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. 20:17 Destination Channel Enable. Four channel enables are defined for controlling which channels are written into the destination region. These channel mask bits are applied in a modulo-four manner to all ExecSize channels. There is 1-bit Channel Enable for each channel within the group of 4. If the bit is cleared, the write for the corresponding channel is disabled. If the bit is set, the write is enabled. Mnemonics for the bit being set for the group of 4 are “x”, “y”, “z”, and “w”, respectively, where “x” corresponds to Channel 0 in the group and “w” corresponds to channel 3 in the group. 0: Write Disabled 1: Write Enabled (normal) 16:15 Dst Type. This field contains the data type for the destination. 00b = Single Precision Float 01b = DWord 10b = Unsigned DWord 11b = Double Precision Float 14:13 Src Type. This field contains the data type for all three sources. 00b = Single Precision Float 01b = DWord 10b = Unsigned DWord 11b = Double Precision Float 12:10 Reserved: MBZ 9:8 Source2 Modifier. This field contains the modifier for source2. Refer to Table 5-5 for the encoding. 7:6 Source1 Modifier. This field contains the modifier for source1. Refer to Table 5-5 for the encoding. 5:4 Source0 Modifier. This field contains the modifier for source0. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 114 Bits Description Refer to Table 5-5 for the encoding. 3 Reserved: MBZ 2 Flag Register Number. This field contains the flag register number for instructions with a non-zero Conditional Modifier. 1 Flag Subregister Number. This field contains the flag subregister number for instructions with a non-zero Conditional Modifier. 0 Reserved 5.2.5 Instruction Source 0 Doubleword 2 (DW2) 5.2.5.1 DW2 1-src and 2-src Instructions Instruction Source 0 Doubleword 2 (DW2) contains the first source operand and also flag register number.  Instruction Source 0 Doubleword 2 (DW2) shows the field definition for Direct Addressing with Align16.  Instruction Source 0 Doubleword 2 (DW2) shows the field definition for Direct Addressing with Align1.  Instruction Source 0 Doubleword 2 (DW2) shows the field definition for Indirect Addressing with Align16.  Instruction Source 0 Doubleword 2 (DW2) shows the field definition for Indirect Addressing with Align1. Instruction Source 0 Doubleword in Direct+Align16 mode Bits Description Reserved: MBZ 31:26 25 FlagSubRegNum – Flag Sub-Register Number. This field specifies the sub-register number for a flag register operand. There are two sub-registers in the flag register. Each sub-register contains 16 flag bits. The selected flag sub-register is the source for predication if predication is enabled for the instruction. It is the destination to store conditional flag bits if conditional modifier is enabled for the instruction. The same flag sub-register can be both the predication source and conditional destination, if both predication and conditional modifier are enabled. 24:21 Src0.VertStride – Source 0 Vertical Stride. This field is the VertStride for src0 operand. It is ignored if src0 is an immediate operand. 20 Reserved: MBZ 19:16 Src0.ChanSel[7:4] This is bits [7:4] of the ChanSel field for src0 operand. 15 Src0.AddrMode – Source 0 Address Mode. This field is the AddrMode for src0 operand. It is ignored if src0 is an immediate operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 115 Bits Description 14:13 Src0.SrcMod – Source 0 Source Modifier. This field is the SrcMod for source operand src0. 12:5 Src0.RegNum – Source 0 Register Number This is the RegNum field for source operand src0. It is ignored if src0 is an immediate operand. 4 Src0.SubRegNum[4] This is the 16-byte aligned sub-register address for source operand src0. It is ignored if src0 is an immediate operand. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. For example, using the F (Float) type the possible subregister numbers in Align16 mode are 0 or 4, corresponding to 0 or 1 for this field. 3:0 Src0.ChanEn – Source 0 Channel Enable This is the ChanEn field for source operand src0. It is ignored if src0 is an immediate operand. Instruction Source 0 Doubleword in Direct+Align1 mode Bits Description Reserved: MBZ 31:26 25 FlagSubRegNum – Flag Sub-Register Number. This field specifies the sub-register number for a flag register operand. 24:21 Src0.VertStride – Source 0 Vertical Stride This is the VertStride field for src0 operand. It is ignored if src0 is an immediate operand. 20:18 Src0.Width. This is the Width field for source operand src0. It is ignored if src0 is an immediate operand. 17:16 Src0.HorzStride. This is the HorzStride field for source operand src0. It is ignored if src0 is an immediate operand. 15 Src0.AddrMode – Source 0 Address Mode. This is the AddrMode for source operand src0. It is ignored if src0 is an immediate operand. 14:13 Src0.SrcMod – Source 0 Source Modifier. This is the SrcMod field for source operand src0. It is ignored if src0 is an immediate operand. 12:5 Src0.RegNum – Source 0 Register Number. This is the RegNum field for source operand src0. It is ignored if src0 is an immediate operand. 4:0 Src0.SubRegNum – Source 0 Sub-Register Number. This is the SubRegNum field for source operand Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 116 Bits Description src0. It is ignored if src0 is an immediate operand. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. Instruction Source 0 Doubleword in Indirect+Align16 mode Bits Description Reserved: MBZ 31:26 25 FlagSubRegNum – Flag Sub-Register Number. This field specifies the sub-register number for a flag register operand. 24:21 Src0.VertStride – Source 0 Vertical Stride. This is the VertStride field for src0 operand. It is ignored if src0 is an immediate operand. 20 Reserved: MBZ 19:16 Src0.ChanSel[7:4] – Source 0 Channel Select. This is bits [7:4] of the ChanSel field for src0 operand. It is ignored if src0 is an immediate operand. 15 Src0.AddrMode – Source 0 Address Mode. This is the AddrMode for source operand src0. It is ignored if src0 is an immediate operand. 14:13 Src0.SrcMod – Source 0 Source Modifier. This is the SrcMod field for source operand src0. It is ignored if src0 is an immediate operand. 12:10 Src0.AddrSubRegNum – Source 0 Address Sub-Register Number. This is the AddrSubRegNum field for source operand src0. It is ignored if src0 is an immediate operand. 9:4 Src0.AddrImm[9:4] – Source 0 Address Immediate. This contains the half-register aligned AddrImm field ((bits [9:4]) for src0. It is ignored if src0 is an immediate operand. 3:0 Src0.ChanEn – Source 0 Channel Enable . This is the ChanEnfield for source operand src0. It is ignored if src0 is an immediate operand. Instruction Source 0 Doubleword in Indirect+Align1 mode Bits Description Reserved: MBZ 31:26 25 FlagSubRegNum – Flag Sub-Register Number. This field specifies the sub-register number for a flag register operand. 24:21 Src0.VertStride – Source 0 Vertical Stride. This is the VertStride field for src0 operand. It is ignored if src0 is an immediate operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 117 Bits Description 20:18 Src0.Width. This is the Width field for source operand src0. It is ignored if src0 is an immediate operand. 17:16 Src0.HorzStride. This is the HorzStride field for source operand src0. It is ignored if src0 is an immediate operand. 15 Src0.AddrMode – Source 0 Address Mode. This is the AddrMode for source operand src0. It is ignored if src0 is an immediate operand. 14:13 Src0.SrcMod – Source 0 Source Modifier. This is the SrcMod field for source operand src0. It is ignored if src0 is an immediate operand. 12:10 Src0.AddrSubRegNum – Source 0 Address Sub-Register Number. This is the AddrSubRegNum field for source operand src0. It is ignored if src0 is an immediate operand. 9:0 Src0.AddrImm – Source 0 Address Immediate. This is the byte aligned AddrImm field for src0. It is ignored if src0 is an immediate operand. This section describes the field in DW2 and DW3 of the 3-src instruction format. Instruction DW2 and DW3 3-Source DW Bits Description Reserved: MBZ DW3 31:30 29:22 Source2 Register Number. This field contains the register number for source2. 21:19 Source2 Subregister Number. This field contains the subregister number for source2. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. 18:11 Source2 Channel Select. This field contains the swizzle control for source2. See ChanSel in the Common Instruction Fieldssection for a description of the Source Swizzle encodings. 10:10 Source2 Replication Control. This field controls replication for source2. See RepCtrl in the Common Instruction Fieldssection for a description of the Source Replication Control encodings. Reserved: MBZ 9:9 8:1 Source1 Register Number. This field contains the register number for source1. 0 Source1 Subregister Number. This field contains the subregister number for source1. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 118 DW Bits Description 31:30 DW2 Source1 Subregister Number. This field contains the subregister number for source1. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. 29:22 Source1 Channel Select. This field contains the swizzle control for source1. See ChanSel in the Common Instruction Fieldssection for a description of the Source Swizzle encodings. 21:21 Source1 Replication Control. This field controls replication for source1. See RepCtrl in the Common Instruction Fieldssection for a description of the Source Replication Control encodings. Reserved: MBZ 20:20 19:12 Source0 Register Number. This field contains the register number for source0. 11:9 Source0 Subregister Number. This field contains the subregister number for source0. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. 8:1 Source0 Channel Select. This field contains the swizzle control for source0. See ChanSel in the Common Instruction Fieldssection for a description of the Source Swizzle encodings. 0:0 Source0 Replication Control. This field controls replication for source0. See RepCtrl in the Common Instruction Fieldssection for a description of the Source Replication Control encodings. 5.2.6 Instruction Source 1 Doubleword 3 (DW3) Instruction Source 1 Doubleword 3 (DW3) contains the second source operand (src1) and is used to hold the 32-bit immediate source (imm32 as src0 or src1). Instruction Source 1 Doubleword 3 (DW3) and Instruction Source 1 Doubleword 3 (DW3) define the fields in this doubleword with the following exceptions:  If src0 is an immediate operand, this doubleword contains imm32 for src0.  If src1 is an immediate operand, this doubleword contains imm32 for src1.  If the instruction is a send, bit 31 of this doubleword contains EOT field. o If src1 is immediate, the remaining 31 bits in this doubleword is MsgDescpt31. o If src1 is a register, src1 must be a0.0. The rest of this doubleword will be configured accordingly.  If indirect address is supported for src1, Instruction Source 1 Doubleword 3 (DW3) and Instruction Source 1 Doubleword 3 (DW3) define the fields in DW3 for indirectly addressed src1 in Align16 and Align1 modes. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 119 Instruction Source 1 Doubleword in Direct + Align16 mode Bits Description Reserved: MBZ 31:25 24:21 Src1.VertStride – Source 1 Vertical Stride. This field is the VertStride for src1 operand. It is ignored if src1 is an immediate operand. 20 Reserved: MBZ 19:16 Src1.ChanSel[7:4] This contains bits [7:6] of the ChanSel field for src1 operand. It is ignored if src1 is an immediate operand. Reserved: MBZ 15 14:13 Src1.SrcMod – Source 1 Source Modifier. This field is the SrcMod for src1 operand. It is ignored if src1 is an immediate operand. 12:5 Src1.RegNum. This field is the RegNum field for src1 operand. It is ignored if src1 is an immediate operand. 4 Src1.SubRegNum[4]. This field is bit [4] of the SubRegNum field for src1. It is ignored if src1 is an immediate operand. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. For example, using the F (Float) type the possible subregister numbers in Align16 mode are 0 or 4, corresponding to 0 or 1 for this field. 3:0 Src1.ChanEn – Source 1 Channel Enable. It is the channel enable field for src1. It is ignored if src1 is an immediate operand. Instruction Source 1 Doubleword in Direct + Align1 mode Bits Description Reserved: MBZ 31:25 24:21 Src1.VertStride – Source 1 Vertical Stride. This field is the VertStride for src1 operand. It is ignored if src1 is an immediate operand. 20:18 Src1.Width. This is the Width field for source operand src1. It is ignored if src1 is an immediate operand. 17:16 Src1.HorzStride. This is the HorzStride field for source operand src1. It is ignored if src1 is an immediate operand. Reserved: MBZ 15 14:13 Src1.SrcMod – Source 1 Source Modifier. This field is the SrcMod for src1 operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 120 Bits Description It is ignored if src1 is an immediate operand. 12:5 Src1.RegNum – Source 1 Register Number. This is the RegNum field for source operand src1. It is ignored if src1 is an immediate operand. 4:0 Src1.SubRegNum – Source 1 Sub-Register Number. This is the SubRegNum field for source operand src1. It is ignored if src1 is an immediate operand. Note: The recommended instruction syntax uses GRF subregister numbers in units of element size, which the assembler translates to the appropriate value for this field. Instruction Source 1 Doubleword in Indirect+Align16 mode Bits Description Reserved: MBZ 31:25 24:21 Src1.VertStride – Source 1 Vertical Stride This is the VertStride field for src1 operand. It is ignored if src1 is an immediate operand. 20 Reserved: MBZ 19:16 Src1.ChanSel[7:4] – Source 1 Channel Select This is bits [7:4] of the ChanSel field for src1 operand. It is ignored if src1 is an immediate operand. 15 Src1.AddrMode – Source 1 Address Mode This is the AddrMode for source operand src1. It is ignored if src1 is an immediate operand. 14:13 Src1.SrcMod – Source 1 Source Modifier This is the SrcMod field for source operand src1. It is ignored if src1 is an immediate operand. 12:10 Src1.AddrSubRegNum – Source 1 Address Sub-Register Number This is the AddrSubRegNum field for source operand src1. It is ignored if src1 is an immediate operand. 9:4 Src1.AddrImm[9:4] – Source 1 Address Immediate This contains the half-register aligned AddrImm field ((bits [9:4]) for src1. It is ignored if src1 is an immediate operand. 3:0 Src1.ChanEn – Source 1 Channel Enable This is the ChanEnfield for source operand src1. It is ignored if src1 is an immediate operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 121 Instruction Source 1 Doubleword in Indirect+Align1 mode Bits Description Reserved: MBZ 31:25 24:21 Src1.VertStride – Source 1 Vertical Stride This is the VertStride field for src1 operand. It is ignored if src1 is an immediate operand. 20:18 Src1.Width This is the Width field for source operand src1. It is ignored if src1 is an immediate operand. 17:16 Src1.HorzStride This is the HorzStride field for source operand src1. It is ignored if src1 is an immediate operand. 15 Src1.AddrMode – Source 1 Address Mode This is the AddrMode for source operand src1. It is ignored if src1 is an immediate operand. 14:13 Src1.SrcMod – Source 1 Source Modifier This is the SrcMod field for source operand src1. It is ignored if src1 is an immediate operand. 12:10 Src1.AddrSubRegNum – Source 1 Address Sub-Register Number This is the AddrSubRegNum field for source operand src1. It is ignored if src1 is an immediate operand. 9:0 Src1.AddrImm – Source 1 Address Immediate This is the byte aligned AddrImm field for src1. It is ignored if src1 is an immediate operand. 5.3 EU Compact Instructions On receiving an instruction with bit 29 (CmptCtrl) set, HW recognizes it as a 64-bit compact instruction. Hardware then uses the index fields inside the compact instruction to lookup values in the associated compaction tables, then uses the table outputs along with other fields in the compact instruction to reconstruct the 128-bit native-sized instruction. In flow control instructions, IP offsets, such as the JIP and UIP instruction fields, are measured in 64-bit QWords. Thus a compact 64-bit instruction is 1 unit for IP offset calculations and a native 128-bit instruction is 2 units for IP offset calculations. The native 128-bit instruction format provides access to all instruction options. Only some instruction options and combinations of instruction options can be represented in the compact instruction formats. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 122 Which native instructions can be represented as compact instructions and the details of the compact instruction formats and the compaction tables used may change with each processor generation. In the following instruction format tables the Mapping Bits and Mapping Description columns describe the mappings into native instruction fields. 5.3.1 EU Compact Instruction Format The following table describes the EU compact instruction format. For this processor, instructions with three source operands cannot be compacted. Compact Instruction Format Mapping Compact Bits Size Bits Name Mapping Description 63:56 8 108:101 Src1.RegNum Src1.RegNum in 108:101 if not immediate. Imm32[7:0] in 103:96 if immediate. (Not Imm.) or 103:96 (Imm.) 55:48 8 76:69 Src0.RegNum Src0.RegNum. 47:40 8 60:53 Dst.RegNum Dst.RegNum. 39:35 5 120:109 Src1Index Lookup one of 32 12-bit values. If not an immediate operand, maps to bits (Not 120:109, covering the Src1.AddrMode, Src1.ChanSel[7:4], Src1.HorzStride, Imm.) Src1.SrcMod, Src1.VertStride, and Src1.Width bit fields. If an immediate or operand, does not do any lookup. The 5-bit value directly maps to bits 108:104 127:104 (Imm32[12:8]) and the upper bit (bit 39 in the compact format, bit 108 in the (Imm.) native format) is replicated to provide bits 127:109 (Imm32[31:13]) in the native format. 34:30 5 88:77 Src0Index Lookup one of 32 12-bit values. That value is used (from MSB to LSB) for the Src0.AddrMode, Src0.ChanSel[7:4], Src0.HorzStride, Src0.SrcMod, Src0.VertStride, and Src0.Width bit fields. Note that this field spans a DWord boundary within the QWord compacted instruction. 29 1 29 CmptCtrl Compaction Control. The same in both the compact and native formats: 0: Regular instruction, not compacted. 1: Compacted instruction. 28 1 Not Reserved Not mapped. MBZ. mapped. 27:24 4 27:24 CondModifier CondModifier. The same in both the compact and native formats. 23 1 28 AccWrCtrl AccWrCtrl. 22:18 5 100:96, SubRegIndex Lookup one of 32 15-bit values. That value is used (from MSB to LSB) for various 68:64, fields for Src1, Src0, and Dst, including ChanEn/ChanSel, SubRegNum, and 52:48 AddrImm[4] or AddrImm[4:0], depending on AddrMode and AccessMode. 17:13 5 63:61, DataTypeIndex Lookup one of 32 18-bit values. That value is used (from MSB to LSB) for the 46:32 Dst.AddrMode, Dst.HorzStride, Dst.DstType, Dst.RegFile, Src0.SrcType, Src0.RegFile, Src1.SrcType, and Src1.RegType bit fields. 12:8 5 ControlIndex 90:89, Lookup one of 32 19-bit values. That value is used (from MSB to LSB) for the 31, 23:8 FlagRegNum, FlagSubRegNum, Saturate, ExecSize, PredInv, PredCtrl, ThreadCtrl, QtrCtrl, DepCtrl, MaskCtrl, and AccessMode bit fields. 6:0 7 6:0 Opcode Opcode. The same in both the compact and native formats. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 123 5.3.1.1 EU Instruction Compaction Tables The following four tables describe the mappings for the ControlIndex, DataTypeIndex, SubRegIndex, Src0Index, and Src1Index fields in the compact instruction format. ControlIndex Compact Instruction Field Mappings ControlIndex 19-Bit Mapping Mapped Meaning 0 0000000000000000010 Align1 | We | (1) | f0.0 1 0000100000000000000 Align1 | (4) | f0.0 2 0000100000000000001 Align16 | (4) | f0.0 3 0000100000000000010 Align1 | We | (4) | f0.0 4 0000100000000000011 Align16 | We | (4) | f0.0 5 0000100000000000100 Align1 | NoDDClr | (4) | f0.0 6 0000100000000000101 Align16 | NoDDClr | (4) | f0.0 7 0000100000000000111 Align16 | We | NoDDClr | (4) | f0.0 8 0000100000000001000 Align1 | NoDDChk | (4) | f0.0 9 0000100000000001001 Align16 | NoDDChk | (4) | f0.0 10 0000100000000001101 Align16 | NoDDClr, NoDDChk | (4) | f0.0 11 0000110000000000000 Align1 | Q1 | (8) | f0.0 12 0000110000000000001 Align16 | Q1 | (8) | f0.0 13 0000110000000000010 Align1 | We | Q1 | (8) | f0.0 14 0000110000000000011 Align16 | We | Q1 | (8) | f0.0 15 0000110000000000100 Align1 | NoDDClr | Q1 | (8) | f0.0 16 0000110000000000101 Align16 | NoDDClr | Q1 | (8) | f0.0 17 0000110000000000111 Align16 | We | NoDDClr | Q1 | (8) | f0.0 18 0000110000000001001 Align16 | NoDDChk | Q1 | (8) | f0.0 19 0000110000000001101 Align16 | NoDDClr, NoDDChk | Q1 | (8) | f0.0 20 0000110000000010000 Align1 | Q2 | (8) | f0.0 21 0000110000100000000 Align1 | Q1 | +f.xyzw | (8) | f0.0 22 0001000000000000000 Align1 | H1 | (16) | f0.0 23 0001000000000000010 Align1 | We | H1 | (16) | f0.0 24 0001000000000000100 Align1 | NoDDClr | H1 | (16) | f0.0 25 0001000000100000000 Align1 | H1 | +f.xyzw | (16) | f0.0 26 0010110000000000000 Align1 | Q1 | (8) | .sat | f0.0 27 0010110000000010000 Align1 | Q2 | (8) | .sat | f0.0 28 0011000000000000000 Align1 | H1 | (16) | .sat | f0.0 29 0011000000100000000 Align1 | H1 | +f.xyzw | (16) | .sat | f0.0 30 0101000000000000000 Align1 | H1 | (16) | f0.1 31 0101000000100000000 Align1 | H1 | +f.xyzw | (16) | f0.1 DataTypeIndex Compact Instruction Field Mappings DataTypeIndex 18-Bit Mapping Mapped Meaning 0 001000000000000001 r:ud | a:ud | a:ud | <1> | dir | 1 001000000000100000 a:ud | r:ud | a:ud | <1> | dir | 2 001000000000100001 r:ud | r:ud | a:ud | <1> | dir | 3 001000000001100001 r:ud | i:ud | a:ud | <1> | dir | 4 001000000010111101 r:f | r:d | a:ud | <1> | dir | 5 001000001011111101 r:f | i:vf | a:ud | <1> | dir | 6 001000001110100001 r:ud | r:f | a:ud | <1> | dir | 7 001000001110100101 r:d | r:f | a:ud | <1> | dir | 8 001000001110111101 r:f | r:f | a:ud | <1> | dir | Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 124 DataTypeIndex 18-Bit Mapping Mapped Meaning 9 001000010000100001 r:ud | r:ud | r:ud | <1> | dir | 10 001000110000100000 a:ud | r:ud | i:ud | <1> | dir | 11 001000110000100001 r:ud | r:ud | i:ud | <1> | dir | 12 001001010010100101 r:d | r:d | r:d | <1> | dir | 13 001001110010100100 a:d | r:d | i:d | <1> | dir | 14 001001110010100101 r:d | r:d | i:d | <1> | dir | 15 001111001110111101 r:f | r:f | a:f | <1> | dir | 16 001111011110011101 r:f | a:f | r:f | <1> | dir | 17 001111011110111100 a:f | r:f | r:f | <1> | dir | 18 001111011110111101 r:f | r:f | r:f | <1> | dir | 19 001111111110111100 a:f | r:f | i:f | <1> | dir | 20 000000001000001100 a:w | a:ub | a:ud | <0> | dir | 21 001000000000111101 r:f | r:ud | a:ud | <1> | dir | 22 001000000010100101 r:d | r:d | a:ud | <1> | dir | 23 001000010000100000 a:ud | r:ud | r:ud | <1> | dir | 24 001001010010100100 a:d | r:d | r:d | <1> | dir | 25 001001110010000100 a:d | a:d | i:d | <1> | dir | 26 001010010100001001 r:uw | a:uw | r:uw | <1> | dir | 27 001101111110111101 r:f | r:f | i:vf | <1> | dir | 28 001111111110111101 r:f | r:f | i:f | <1> | dir | 29 001011110110101100 a:w | r:w | i:w | <1> | dir | 30 001010010100101000 a:uw | r:uw | r:uw | <1> | dir | 31 001010110100101000 a:uw | r:uw | i:uw | <1> | dir | SubRegIndex Compact Instruction Field Mappings SubRegIndex 15-Bit Mapping Mapped Meaning 0 000000000000000 0 | 0 | 0 | 1 000000000000001 0.x | 0.xx | 0.xx 2 000000000001000 8 | 0 | 0 | 3 000000000001111 0.xyzw | 0.xx | 0.xx 4 000000000010000 16 | 0 | 0 | 5 000000010000000 0 | 4 | 0 | 6 000000100000000 0 | 8 | 0 | 7 000000110000000 0 | 12 | 0 | 8 000001000000000 0 | 16 | 0 | 9 000001000010000 16 | 16 | 0 | 10 000001010000000 0 | 20 | 0 | 11 001000000000000 0 | 0 | 4 | 12 001000000000001 0.x | 0.xx | 0.xy 13 001000010000001 0.x | 0.xy | 0.xy 14 001000010000010 0.y | 0.xy | 0.xy 15 001000010000011 0.xy | 0.xy | 0.xy 16 001000010000100 0.z | 0.xy | 0.xy 17 001000010000111 0.xyz | 0.xy | 0.xy 18 001000010001000 0.w | 0.xy | 0.xy 19 001000010001110 0.yzw | 0.xy | 0.xy 20 001000010001111 0.xyzw | 0.xy | 0.xy 21 001000110000000 0 | 12 | 4 | 22 001000111101000 0.w | 0.ww | 0.xy 23 010000000000000 0 | 0 | 8 | 24 010000110000000 0 | 12 | 8 | Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 125 SubRegIndex 15-Bit Mapping Mapped Meaning 25 011000000000000 0 | 0 | 12 | 26 011110010000111 0.xyz | 0.xy | 0.ww 27 100000000000000 0 | 0 | 16 | 28 101000000000000 0 | 0 | 20 | 29 110000000000000 0 | 0 | 24 | 30 111000000000000 0 | 0 | 28 | 31 111000000011100 28 | 0 | 28 | Src0Index or Src1Index Compact Instruction Field Mappings Src0Index or Src1Index 12-Bit Mapping Mapped Meaning 0 000000000000 dir | <0;1,0> 1 000000000010 (-) | dir | <0;1,0> 2 000000010000 dir | <0;>.zx 3 000000010010 (-) | dir | <0;>.zx 4 000000011000 dir | <0;>.wx 5 000000100000 dir | <0;>.xy 6 000000101000 dir | <0;>.yy 7 000001001000 dir | <0;4,1> 8 000001010000 dir | <0;>.zz 9 000001110000 dir | <0;>.zw 10 000001111000 dir | <0;8,4> / dir | <0;>.ww 11 001100000000 dir | <4;>.xx 12 001100000010 (-) | dir | <4;>.xx 13 001100001000 dir | <4;>.yx 14 001100010000 dir | <4;>.zx 15 001100010010 (-) | dir | <4;>.zx 16 001100100000 dir | <4;>.xy 17 001100101000 dir | <4;>.yy 18 001100111000 dir | <4;>.wy 19 001101000000 dir | <4;4,0> 20 001101000010 (-) | dir | <4;4,0> 21 001101001000 dir | <4;>.yz 22 001101010000 dir | <4;>.zz 23 001101100000 dir | <4;>.xw 24 001101101000 dir | <4;>.yw 25 001101110000 dir | <4;>.zw 26 001101110001 (abs) | dir | <4;>.zw 27 001101111000 dir | <4;>.ww 28 010001101000 dir | <8;8,1> 29 010001101001 (abs) | dir | <8;8,1> 30 010001101010 (-) | dir | <8;8,1> 31 010110001000 dir | <16;16,1> Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 126 5.4 Opcode Encoding Byte 0 of the 128-bit instruction word contains the opcode. The opcode uses 7 bits. Bit location 7 in byte 0 is reserved for future opcode extension. The opcodes are encoded and organized into five groups based on the type of operations: Special instructions, move/logic instructions (opcode=00xxxxxb), flow control instructions (opcode=010xxxxb), miscellaneous instructions (opcode=011xxxxb), parallel arithmetic instructions (opcode=100xxxxb), and vector arithmetic instructions (opcode=101xxxxb). Opcodes 110xxxb are reserved. Note: Opcodes appear in the overall Instruction Set Summary Table as well. The following subsections still serve the purpose of describing various instruction groups. 5.4.1 Move and Logic Instructions This instruction group has an opcode format of 00xxxxxb.  The opcodes for move instructions (mov, sel and movi) share the common 5 MSBs in the form of 00000xxb.  The opcodes for logic instructions (not, and, or, and xor) share the common 5 MSBs in the form of 00001xxb.  The opcodes for shift instructions (shr, shl, and asr) share the common 4 MSBs in the form of 0001xxxb. Bit 2 indicates arithmetic or logic shift (0 = logic, 1 = arithmic). Bit 1 is always 0 (which is reserved for future extension to support rotation shift as 0 = shift, 1 = rotate). Bit 0 indicates the shift direction (0 = right, 1 = left).  The opcodes for compare instructions (cmp and cmpn) share the common 6 MSBs in the form of 001000xb. Bit 0 indicates whether it is a normal compare, cmp, or a special compare-NaN, cmpn. Move and Logic Instructions Opcode dec hex Instruction Description #src #dst 1 0x01 Component-wise move 1 1 mov 2 0x02 Component-wise selective move based on predication 2 1 sel 3 0x03 Fast component-wise indexed move 1 1 movi 4 0x04 Component-wise one's complement (bitwise not) 1 1 not 5 0x05 Component-wise logical AND (bitwise and) 2 1 and 6 0x06 Component-wise logical OR (bitwise or) 2 1 or 7 0x07 Component-wise logical XOR (bitwise xor) 2 1 xor 8 0x08 Component-wise logical shift right 2 1 shr 9 0x09 Component-wise logical shift left 2 1 shl 11 0x0A Reserved Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 127 Opcode dec hex Instruction Description #src #dst 12 0x0C Component-wise arithmetic shift right 2 1 asr 13 0x0D Reserved 14 0x0E Reserved 15 0x0F Reserved 16 0x10 Component-wise compare, store condition code in destination 2 1 cmp 17 0x11 Component-wise compare-NaN, store condition code in destination 2 1 cmpn 18 0x12 Reserved 19 0x13 f32tof16 Single precision float to half precision float conversion 20 0x14 f16to32 Half precision float to single precision float conversion 21 0x15 Reserved 22 0x16 Reserved 23 0x17 Reverse bits 1 1 bfrev 24 0x18 Bitfield exact 3 1 bfe 25 0x19 Bitfield insert macro instruction 1, generate mask 2 1 bfi1 26 0x1A bfi2 27-31 0x1B-0x1F Reserved 5.4.2 Flow Control Instructions This instruction group has an opcode format of 010xxxxb. Flow Control Instructions Opcode dec hex Instruction Description #src #dst 32 0x20 Jump indexed 1 0 jmpi 0x21 Branch - Diverging 1 0 33 brd 34 0x22 If 0/2 0 if 35 0x23 Branch - Converging 1 - brc 36 0x24 Else 1 0 else 37 0x25 End if 0 0 endif Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 128 Opcode dec hex Instruction Description #src #dst 38 0x26 Case – Inside Switch block 0/2 0 case 39 0x27 While 1 0 while 40 0x28 Break 1 0 break 41 0x29 Continue 1 0 cont 42 0x2A Halt 1 0 halt 43 0x2B Reserved 44 0x2C Subroutine call 1 1 call 45 0x2D Subroutine return 1 1 return 46 0x2E Reserved 47 0x2F Reserved 5.4.3 Miscellaneous Instructions This instruction group has an opcode format of 011xxxxb. Miscellaneous Instructions Opcode Instruction #dst dec hex Description #src 48 0x30 Wait for (external) notification 1 0 wait 49 0x31 Send 1 1 send 50 0x32 Conditional Send (based on TDR) 1 1 sendc 51-55 0x33-0x37 Reserved 56 0x38 Math functions for extended math pipeline 1/2 1/2 math 57-63 0x39-0x3F Reserved Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 129 5.4.4 Parallel Arithmetic Instructions This instruction group has an opcode format of 100xxxxb. Parallel Arithmetic Instructions Opcode Instruction #dst dec hex Description #src 64 0x40 Component-wise addition 2 1 add 65 0x41 Component-wise multiply 2 1 mul 66 0x42 Component-wise average of the two source operands 2 1 avg 67 0x43 Component-wise floating point truncate-to-minus-infinity 1 1 frc fraction 68 0x44 Component-wise floating point rounding up (ceiling) 1 1 rndu 69 0x45 Component-wise floating point rounding down (floor) 1 1 rndd 70 0x46 Component-wise floating point rounding toward nearest even 1 1 rnde 71 0x47 Component-wise floating point rounding toward zero 1 1 rndz 72 0x48 Component-wise multiply accumulate 2 1 mac 73 0x49 multiply accumulate high 2 1 mach 74 0x4A leading zero detection 1 1 lzd 75 0x4B Find first 1 for UD from msb side, or first 1/0 for D. 1 1 fbh 76 0x4C First first 1 for UD from lsb side 1 1 fbl 77 0x4D Count bits set 1 1 cbit 78 0x4E Integer add with carry 2 1+ addc acc. 79 0x4F integer subtract with borrow 2 1+ subb acc. 75-79 0x4B- Reserved 0x4F Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 130 5.4.5 Vector Arithmetic Instructions This instruction group has an opcode format of 101xxxxb. Vector Arithmetic Instructions Opcode dec hex Instruction Description #src #dst 80 0x50 2-wide sum of absolute difference 2 1 sad2 81 0x51 2-wide sad accumulate 2 1 sada2 82- 0x52-0x53 reserved 83 84 0x54 4-wide dot product for 4-vector 2 1 dp4 85 0x55 4-wide homogenous dot product for 4-vector 2 1 dph 86 0x56 3-wide dot product for 4-vector 2 1 dp3 87 0x57 2-wide dot product for 4-vector 2 1 dp2 88 0x58 reserved 89 0x59 Component-wise line equation computation (a multiply-add) 2 1 line 90 0x5A Component-wise floating point plane equation computation (a multiply-multiply- 2 1 pln add) 91 0x5B Component-wise floating point mad computation (a multiple-add) 3 1 fma(mad) 92 0x5C Component-wise floating point lrp computation (blend) 3 1 lrp 93 0x5D reserved 94- 0x5D- reserved 95 0x5F 5.4.6 Special Instructions There are two special instructions, namely, nop (opcode = 0x7E) and illegal (opcode = 0x00).  Nop instruction may be used for instruction padding in memory between two normal instructions to force alignment or to introduce instruction execution delay. Currently, there is no need for between- instruction padding.  Illegal instruction may be used for instruction padding in memory outside the normal instruction sequence such as before or after the kernel program as well as between subroutines.  Nop and illegal instructions do not have source operands or destination operand. Therefore, they do not implicitly update the accumulator register. They cannot be compressed. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 131 Special Instructions Opcode dec hex Instruction Description #src #dst 0 0x00 Illegal instruction 0 0 illegal 96-124 0x60-0x7D Reserved 126 0x7E No-op 0 0 nop (may be used as an extension code) 127 0x7F Reserved 5.5 Native Instruction BNF The Backus-Naur Form (BNF) grammar identifies the assembly language syntax, which is native to the hardware. It does not include intelligent defaults, assembler pragmas, etc. 5.5.1 Instruction Groups ::= | | | | | | | | | | | | | | ::= dst ::= ::= “mov” | “frc” | “rndu” | “rndd” | “rnde” | “rndz” | “not” | “lzd” ::= dst ::= ::= “mul” | “mac” | “mach” | “line”” | “pln” |“sad2” | “sada2” | “dp4” | “dph” | “dp3” | “dp2”” | “Irp”” | “bfi1”” | “addc”” | “subb” ::= dst Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 132 ::= ::= “avg” | “add” | “sel” |“and” | “or” | “xor” |“shr” | “shl” | “asr” |“cmp” | “cmpn” ::= ::= ::= “send” ::= dst ::= , ::= “bfe”| “bfi2”|”mad” ::= < RelativeLocation2> ::= “brc” ::= < RelativeLocation3> ::= “brd” ::= dst< RelativeLocation2> ::= “call” |”CALLA” ::= < Dst>< Src>< Src> ::= ::= “math” ::= “INV” | “LOG” | “EXP” | “SQRT” |”RSQ” | “POW” | “SIN” | “COS” | “INT DIV” ::= ::= “jmpi” ::= < RelativeLocation> ::=“if” | “iff” | “while” ::= < RelativeLocation> ::=“else” ::= ::=“break” | “cont” | “halt” ::= ::=“wait” ::=“do” | “endif” |“nop” | “illegal” Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 133 5.5.2 Destination Register dst::= | ::= ::= | | | | | | | | | | ::= | | | ::= | ::= | ::= 5.5.3 Source Register Source with Accumulator Access and with Immediate ::= | ::= | ::= | | ::= | Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 134 | | | | | | | | ::= Source without Accumulator Access ::= | < DirectSrcOperand>::= | ::= | ::= | ::= Source without Accumulator Access or IP Access ::= | 5.5.4 Address Registers ::= ::= “” | “,” 5.5.5 Register Files and Register Numbers Note: The recommended instruction syntax uses subregister numbers within the GRF in units of actual data element size, corresponding to the data type used. For example for the F (Float) type, the assembler syntax uses subregister numbers 0 to 7, corresponding to subregister byte addresses of 0 to 28 in steps of 4, the element size. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 135 ::= ::= “[“ “]” ::=“r” :: =“0”…“127” :: = “” | “.0”…”.3” //incase of DF | “.0”...“.7” | “.0”...“.15” | “.0”...“.31” ::= ::= ::= “[“ “]” ::=“m” :: =“0”…“15” :: = ::= ::=“a0” :: = “” | “.0” … “.7” ::=“acc” :: =“0” | “1” :: = ::= “f” :: = “0” | “1” ::=“f0” :: =“” | “.0”...“.1” ::=“n” :: =“0”...“2” ::=“sr0” :: =“.0”... “.1” ::=“cr0” :: =“.0” ...“.2” ::=“ip” ::=“null” Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 136 ::= “tdr0” ::= “.0”…“.7” ::= “tm0” ::= “ce0.0” 5.5.6 Relative Location and Stack Control ::= ::= | ::= | ::= 5.5.7 Regions ::=“<” “>” ::= | | ::=“<” “;” “,” “>” ::=“<” “,” “>” ::=“<” “>” ::= “0” | “1” | “2” | “4” | “8” | “16” | “32” ::=“1” | “2” | “4” | “8” | “16” ::=“0” | “1” | “2” | “4” 5.5.8 Types ::= “:df” | “:f” | “:ud” | “:d” | “:uw” | “:w” | “:ub” | “:b” ::= | “:v” | “:vf” | “:uv” ::= 5.5.9 Write Mask ::= “” | “.” “x” | “.” “y” | “.” “z” | “.” “w” | “.” “xy” | “.” “xz” | “.” “xw” | “.” “yz” | “.” “yw” | “.” “zw” | “.” “xyz” | “.” “xyw” | “.” “xzw” | “.” “yzw” | “.” “xyzw” Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 137 5.5.10 Swizzle Control ::=“” | “.” | “.” ::= “x” | “y” | “z” | “w” 5.5.11 Immediate Values ::=“-512”… “511” ::= “0.0”… “±1.0*2-1024…1023” | “0”…”264-1” | “-263”…”263-1” ::=“0.0”… “±1.0*2-128…127” | “0”…”232-1” | “-231”…”231-1” ::=“0”…”216-1” | “-215”…”215-1” ::=“0”…”232-1” 5.5.12 Predication and Modifiers Instruction Predication ::=“” |“(” “)” ::=“” |“+” |“-“ ::=“” |“.x” | “.y” | “.z” | “.w” |“.any2h” | “.all2h” |“.any4h” | “.all4h” |“.any8h” | “.all8h” |“.any16h” | “.all16h” |“.anyv” | “.allv” | “.any32h”| “.all32h” Source Modification ::=“” |“-” |“(abs)” |“-” “(abs)” Instruction Modification ::=“” Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 138 | “. ” ::=“.z” | “.e”|“.nz” | “.ne”|“.g”|“.ge”|“.l”|“.le”|“.o” |“.r” |“.u” ::=“” |“.sat” Execution Size ::=“(“ “)” ::=“1” | “2” | “4” | “8” | “16” | “32” 5.5.13 Instruction Options ::= “” | “{” “}” | “{” “}” ::= “” | “,” ::= | | | | | | ::= “Align1” | “Align16” ::= “AccWrEn” ::= “SecHalf” | “Compr” ::= “NoDDChk” | “NoDDClr” ::= “NoMask” ::= “EOT” ::= “Switch” +: | “Atomic” Note for Assembler: Compression control “Compr” has a direct map to the binary instruction word. It may be omitted if the Assembler can determine whether an instruction is compressable. 5.6 Instruction Set Summary Tables The columns in the following tables specify instruction mnemonics, hex opcodes, full names, instruction groups, the number of source operands, whether the instruction supports predication, any support for Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 139 source modifiers, an indication of supported data types, whether the instruction supports saturation, and any support for conditional modifiers. See the separate Accumulator Restrictions table for information about how instructions are allowed to use accumulators. N and Y indicate No (no support for a feature) and Yes (full support for a feature) respectively. A SrcMod (source modifier) value of Y indicates that a numeric source modifier is allowed, optionally specifying abolute value, negation, or a forced negative value. The value N indicates no source modifier support. A SrcMod value of ** indicates a numeric source modifier. In the Src Types and Dst Type columns, Int means any integer type and * means such an extensive list of types that you must refer to the detailed instruction description. Instruction Set Summary Table A to B (Listed by Instruction Mnemonic) Hex Mnem. Opcode Name Group Srcs Pred? SrcMod Src Types Dst Type Sat? CondMod? add 40 Addition Parallel Arithmetic 2 Y Y * * Y Y addc 4E Integer Addition with Carry Parallel Arithmetic 2 Y N UD UD N Y and 05 Logic And Move and Logic 2 Y ** Int Int N Equality only asr 12 Arithmetic Shift Right Move and Logic 2 Y Y Int Int Y Y avg 42 Average Parallel Arithmetic 2 Y Y B, UB B, UB Y Y W, UW W, UW D, UD D, UD bfe 18 Bit Field Extract Move and Logic 3 Y N UD, D UD, D N N bfi1 19 Bit Field Insert 1 Move and Logic 2 Y N UD, D UD, D N N bfi2 1A Bit Field Insert 2 Move and Logic 3 Y N UD, D UD, D N N bfrev 17 Bit Field Reverse Move and Logic 1 Y N UD UD N N brc 23 Branch Converging Flow Control 0 or 1 Y N D N N brd 21 Branch Diverging Flow Control 0 or 1 Y N D N N break 28 Break Flow Control 0 Y N N N Instruction Set Summary Table C to E (Listed by Instruction Mnemonic) Hex Mnem. Opcode Name Group Srcs Pred? SrcMod Src Types Dst Type Sat? CondMod? call 2C Call Flow Control 0 Y N D, UD N N cbit 4D Count Bits Set Move and Logic 1 Y N UB, UW, UD UD N N cmp 10 Compare Move and Logic 2 Y Y * * N Y cmpn 11 Compare NaN Move and Logic 2 Y Y * * N Y cont 29 Continue Flow Control 0 Y N N N dp2 57 Dot Product 2 Vector Arithmetic 2 Y Y F F Y Y dp3 56 Dot Product 3 Vector Arithmetic 2 Y Y F F Y Y dp4 54 Dot Product 4 Vector Arithmetic 2 Y Y F F Y Y dph 55 Dot Product Homogeneous Vector Arithmetic 2 Y Y F F Y Y else 24 Else Flow Control 0 N N N N endif 25 End If Flow Control 0 N N N N Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 140 Instruction Set Summary Table F to L (Listed by Instruction Mnemonic) Hex Mnem. Opcode Name Group Srcs Pred? SrcMod Src Types Dst Type Sat? CondMod? f16to32 14 Half Precision Float to Move and Logic 1 Y Y W F Y Y Single Precision Float f32to16 13 Single Precision Float to Move and Logic 1 Y Y F W Y Y Half Precision Float fbh 4B Find First Bit from MSB Side Move and Logic 1 Y N D, UD UD N N fbl 4C Find First Bit from LSB Side Move and Logic 1 Y N UD UD N N frc 43 Fraction Parallel Arithmetic 1 Y Y F F N Y halt 2A Halt Flow Control 0 Y N N N if 22 If Flow Control 0 Y N N N illegal 00 Illegal Special 0 N N N N jmpi 20 Jump Indexed Flow Control 1 Y N D N N line 59 Line Vector Arithmetic 2 Y Y F F Y Y lrp 5C Linear Interpolation Vector Arithmetic 3 Y Y F F N Y lzd 4A Leading Zero Detection Move and Logic 1 Y Y D, UD UD Y Y Instruction Set Summary Table M to P (Listed by Instruction Mnemonic) Hex Mnem. Opcode Name Group Srcs Pred? SrcMod Src Types Dst Type Sat? CondMod? mac 48 Multiply Accumulate Parallel Arithmetic 2 Y Y * * Y Y mach 49 Multiply Accumulate High Parallel Arithmetic 2 Y Y * * Y Y mad 5B Multiply Add Parallel Arithmetic 3 Y Y * * Y Y math 38 Extended Math Function Parallel Arithmetic 2 Y N * * Y N mov 01 Move Move and Logic 1 Y Y * * Y Y movi 03 Move Indexed Move and Logic 1 Y Y * * Y N mul 41 Multiply Parallel Arithmetic 2 Y Y * * Y Y nop 7E No Operation Special 0 N N N N not 04 Logic Not Move and Logic 1 Y ** Int Int N Equality only or 06 Logic Or Move and Logic 2 Y ** Int Int N Equality only pln 5A Plane Vector Arithmetic 2 Y Y F F Y Y Instruction Set Summary Table R to X (Listed by Instruction Mnemonic) Hex Mnem. Opcode Name Group Srcs Pred? SrcMod Src Types Dst Type Sat? CondMod? ret 2D Return Flow Control 1 Y N D, UD N N rndd 45 Round Down Parallel Arithmetic 1 Y Y F F Y Y rnde 46 Round to Nearest or Even Parallel Arithmetic 1 Y Y F F Y Y rndu 44 Round Up Parallel Arithmetic 1 Y Y F F Y Y rndz 47 Round to Zero Parallel Arithmetic 1 Y Y F F Y Y sad2 50 Sum of Absolute Difference 2 Vector Arithmetic 2 Y Y B, UB W, UW Y Y sada2 51 Sum of Absolute Difference Accumulate 2 Vector Arithmetic 2 Y Y B, UB W, UW Y Y sel 02 Select Move and Logic 2 Y Y * * Y Y send 31 Send Message Miscellaneous 1 Y N * * N N sendc 32 Conditional Send Message Miscellaneous 1 Y N * * N N shl 09 Shift Left Move and Logic 2 Y Y Int Int Y Y shr 08 Shift Right Move and Logic 2 Y Y Int Int Y Y subb 4F Integer Subtraction with Borrow Parallel Arithmetic 2 Y N UD UD N Y wait 30 Wait Miscellaneous 1 N N UD UD N N while 27 While Flow Control 0 or 2 Y N * * N Y while 27 While Flow Control 0 Y N N N xor 06 Logic Xor Move and Logic 2 Y ** Int Int N Equality only Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 141 5.7 Accumulator Restrictions This section describes restrictions on accumulator access: general restrictions, restrictions for specific instructions, and how those specific restrictions vary for processor generations. See Accumulator Registersfor a description of the accumulator registers. Accumulator registers can be accessed as explicit source or destination operands, as an implicit source value when specified for a particular instruction (sada2 for example), and as an implicit destination when the AccWrEn instruction option is used. These general rules apply to accumulator access: 1. Flow control, send, sendc, and wait instructions cannot use accumulators. 2. Instructions with three source operands cannot use explicit accumulator operands. AccWrEn may be allowed for implicitly updating the accumulator. 3. Instructions that use the accumulator as an implicit source value cannot specify an explicit accumulator source operand. 4. Instructions that specify an implicit accumulator destination (with AccWrEn) cannot specify an explicit accumulator destination operand. 5. An instruction with both an explicit accumulator source operand and an explicit accumulator destination operand must specify the same accumulator register as the source and the destination. These descriptions are frequently used in this table:  No restrictions.  No accumulator access, implicit or explicit.  Source operands cannot be accumulators.  Source modifier is not allowed if source is an accumulator.  Accumulator is an implicit source and thus cannot be an explicit source operand.  Accumulator cannot be destination, implicit or explicit.  AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. These minor cases occur occasionally in the table:  Integer source operands cannot be accumulators.  No explicit accumulator access because this is a three-source instruction. AccWrEn is allowed for implicitly updating the accumulator.  An accumulator can be a source or destination operand but not both. A few instructions use more than one of the listed restrictions. Accumulator Restrictions Instruction Description add No restrictions. addc AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. and Source modifier is not allowed if source is an accumulator. asr No restrictions. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 142 Instruction Description avg No restrictions. bfe No accumulator access, implicit or explicit. bfi1 No accumulator access, implicit or explicit. bfi2 No accumulator access, implicit or explicit. bfrev No accumulator access, implicit or explicit. cbit No accumulator access, implicit or explicit. cmp Accumulator cannot be destination, implicit or explicit. cmpn Accumulator cannot be destination, implicit or explicit. dp2 Source operands cannot be accumulators. dp3 Source operands cannot be accumulators. dp4 Source operands cannot be accumulators. dph Source operands cannot be accumulators. f16to32 No accumulator access, implicit or explicit. f32to16 No accumulator access, implicit or explicit. fbh No accumulator access, implicit or explicit. fbl No accumulator access, implicit or explicit. frc No restrictions. line Source operands cannot be accumulators. lrp No explicit accumulator access because this is a three-source instruction. AccWrEn is allowed for implicitly updating the accumulator. lzd Accumulator cannot be destination, implicit or explicit. mac Accumulator is an implicit source and thus cannot be an explicit source operand. mach Accumulator is an implicit source and thus cannot be an explicit source operand. AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. mad No explicit accumulator access Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 143 Instruction Description because this is a three-source instruction. AccWrEn is allowed for implicitly updating the accumulator. math No accumulator access, implicit or explicit. mov An accumulator can be a source or destination operand but not both. movi Source operands cannot be accumulators. mul Source operands cannot be accumulators. not Source modifier is not allowed if source is an accumulator. or Source modifier is not allowed if source is an accumulator. pln Source operands cannot be accumulators. rndd No accumulator access, implicit or explicit. rnde No accumulator access, implicit or explicit. rndu No accumulator access, implicit or explicit. rndz No accumulator access, implicit or explicit. sad2 Source operands cannot be accumulators. sada2 Source operands cannot be accumulators. sel No restrictions. shl Accumulator cannot be destination, implicit or explicit. shr No restrictions. subb AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. xor Source modifier is not allowed if source is an accumulator. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 144 6. Instruction Set Reference This chapter describes the functions of instructions. Each instruction is sorted in alphabetical order according to assembly language mnemonic. 6.1 Conventions This section describes conventions used in instruction reference pages. For each instruction that has source or destination types, a table lists the allowed type combinations and may also indicate the processor generations that support certain combinations. A notation like *W indicates that UW and W are both allowed. Multiple types listed together mean that any combination (Cartesian product) of the listed types is allowed. If a source operand is floating-point, all source operands must have the same floating-point data type. Accumulator restrictions are described in the Accumulator Restrictions section and also appear in instruction descriptions. 6.1.1 Pseudo Code Format Instructions are explained in the following pseudo-code format that resembles the GEN assembly instruction format. [(pred)] opcode (exec_size) dst src0 [src1] Square brackets “[ ]” indicate that a field is optional. Saturation modifiers and instruction options are omitted for simplicity. 6.1.2 General Macros and Definitions INST_MIN_SIZE is defined as a constant of 8 bytes. #define INST_MIN_SIZE 8 // Instruction minimum size in bytes (for the compact instruction format) The floor function converts a floating point value to an integral floating point value. For a given floating point value, from its closest two integral float values, floor returns the one that is closer to negative infinity. For example, floor(1.3f) = 1.0f and floor(-1.3f) = -2.0f. float floor(float g) { return maximum(any integral float f: f <= g) } The Condition function takes the conditional signals {SN, ZR, OF, IN, NC} of result, generates a Boolean value according to a conditional evaluation controlled by the conditional modifier cmod, and returns the Boolean. Bool Condition(result, cmod) Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 145 The ConditionNaN function takes the conditional signals {SN, ZR, OF, IN, NC, NS} of result, generates a Boolean value according to a conditional evaluation controlled by the conditional modifier cmod, and returns the Boolean. The only difference between Condition and ConditionNaN is that ConditionNaN uses the NS (NaN of the second source) signal. Bool ConditionNaN(result, cmod) The Jump function jumps the instruction sequence from the current instruction location by InstCount 8- byte units, where each 16-byte native instruction is two units and each 8-byte compact instruction is one unit. If InstCount is positive and greater than zero, is an unconditional jump forward. If InstCount is negative, is an unconditional jump backward. If InstCount is zero, IP stays on the current instruction in an infinite loop. void Jump(int InstCount) { IP = IP + (InstCount * INST_MIN_SIZE) } 6.2 Evaluate Write Enable The WrEn should be evaluated as below. Note: MaskCtrl = NoMask (1) skips the check for PcIP[n] == ExIP before enabling a channel. if ( MaskCtrl == 1 ) { for ( n = 0; n < exec_size; n++ ) { WrEn[n] = 1; } } else { for ( n = 0; n < exec_size; n++ ) { if ( PcIP[n] == ExIP ) { WrEn[n] = 1; } else { WrEn[n] = 0; } } } if ( PredCtrl != 0000b ) { for ( n = 0; n < exec_size; n++ ) { WrEn[n] = WrEn[n] & PMask[n]; } } for ( n = exec_size; n < 32; n++ ) { WrEn[n] = 0; } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 146 6.3 Instruction Description The rest of the chapter contains the description of instructions. 6.4 add – Addition Opcode Instruction Description 64 (0x40) add dst src0 src1 Add src0 and src1 storing the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type *B, *W, *D *B, *W, *D *B, *W, *D F F F DF DF Format: [(pred)] add[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] add[.cmod] (exec_size) reg reg reg [(pred)] add[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] + src1.chan[n]; } } Description: The add instruction performs component-wise addition of src0 and src1 and stores the results in dst. Addition of two floating-point numbers follows rules in add – Addition or add – Addition). Note: Use a source modifier with add to implement subtraction. Floating-Point Addition of A (Column) and B (Row) in IEEE Mode –inf –finite –denorm –0 +0 +denorm +finite +inf NaN –inf –inf –inf –inf –inf –inf –inf –inf NaN NaN –finite –inf * A A A A ** +inf NaN –inf B B +inf NaN –0/ –0/ +0/ +0/ -denorm/ +denorm/ -denorm^ -denorm^ -finite^ -denorm^ –denorm Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 147 –inf B –0 +0 B +inf NaN –0/ +0/ -denorm^ +denorm –0 –inf B +0 +0 B +inf NaN +0/ +0/ -denorm^ +denorm +0 –inf B B +inf NaN +0/ +0/ +0/ +0/ +denorm/ +denorm^ +denorm^ +denorm/ -denorm^ +finite^ +denorm +finite –inf ** A A A A *** +inf NaN +inf NaN +inf +inf +inf +inf +inf +inf +inf NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN Notes: ^ Non zero results are applicable when denorm is enabled. * Result can be { –finite}. ** Result can be {–finite, –0, +0, +finite}. *** Result can be { +finite}. Floating-Point Addition of A (Column) and B (Row) in ALT Mode –fmax –finite –denorm –0 +0 +denorm +finite +fmax **** –fmax –fmax –fmax –fmax –fmax –fmax –fmax –finite +0 –finite –fmax * A A A A ** +fmax –denorm –fmax B –0 –0 +0 +0 B +fmax –0 –fmax B –0 –0 +0 +0 B +fmax +0 –fmax B +0 +0 +0 +0 B +fmax +denorm –fmax B +0 +0 +0 +0 B +fmax +finite –finite ** A A A A *** +fmax +fmax +0 +fmax +fmax +fmax +fmax +fmax +fmax +fmax **** Notes: * Result can be { –fmax, –finite}. ** Result can be {–finite, –0, +0, +finite}. *** Result can be { +fmax, +finite}. **** Result is undefined if A or B is {–inf, +inf, NaN}. 6.5 addc – Integer Addition with Carry Opcode Instruction Description 78 (0x4E) addc dst src0 src1 Add 32-bit unsigned integers src0 and src1. Store the 32-bit result in dst. Store the carry out (0 or 1) as a 32-bit value in the accumulator. Pred Sat Cond Mod Src Mod Y N Y N Src Types Dst Type UD UD Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 148 Format: [(pred)] addc[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] addc[.cmod] (exec_size) reg reg reg [(pred)] addc[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] + src1.chan[n]; acc.chan[n] = carry(src0.chan[n] + src1.chan[n]); } } Description: The addc instruction performs component-wise addition of src0 and src1 and stores the results in dst; it also stores the carry into acc. If the operation produces a carry out, 0x00000001 is stored in acc, else 0x00000000 is stored in acc. Restrictions: AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. 6.6 and – Logic And Opcode Instruction Description 5 (0x05) and dst src0 src1 Performing component-wise logic AND of src0 and src1 and storing the results in dst. Pred Sat Cond Mod Src Mod Y N Y Y Generation Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] and[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] and[.cmod] (exec_size) reg reg reg [(pred)] and[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] & src1.chan[n]; Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 149 } } Description: The and instruction performs component-wise logic AND operation between src0 and src1 and stores the results in dst. Register source operands can use source modifiers:  Any source modifier is numeric, optionally changing a source value s to -s, abs(s), or -abs(s) before the AND operation. This operation does not produce sign or overflow conditions. Only the .e/.z or .ne/.nz conditional modifiers should be used. Restrictions: Source modifier is not allowed if source is an accumulator. 6.7 asr – Arithmetic Shift Right Opcode Instruction Description 12 (0x0C) asr dst src0 src1 Arithmetic shift the bits in src0 right by the number of bits indicated in src1. Store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Generation Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] asr[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] asr[.cmod] (exec_size) reg reg reg [(pred)] asr[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.channel[n] ) { shiftCnt = src1.chan[n] & 0x1F; // Always use low 5 bits for shift count. if (src0.chan[n] >= 0) { dst.chan[n] = src0.chan[n] >> shiftCnt; } else { int maskLSB = pow(2, shiftCnt) – 1; if ( maskLSB & src0.chan[n] == 0 ) { dst.chan[n] = sign(src0.chan[n]) * ((abs)src0.chan[n] >> shiftCnt); Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 150 } else { dst.chan[n] = sign(src0.chan[n]) * ((abs)src0.chan[n] >> shiftCnt) – 1; } } } } Description: Perform component-wise arithmetic right shift of the bits in src0 by the shift count indicated in src1, storing the results in dst. If src0 has a signed type, insert copies of src0's sign bit in the number of MSBs indicated by the shift count. Otherwise insert 0 bits. The shift count is taken from the low five bits of src1, regardless of the src1 type and treated as an unsigned integer in the range 0 to 31. For positive values, this operation is src0 / 2shiftCount and for negative values, this operation is src0 / 2shiftCount - 1. Note: If src0 is -1, the result is -1 regardless of the shift count. Note: For unsigned src0 types, asr and shr produce the same result. 6.8 avg – Average Opcode Instruction Description 66 (0x42) avg dst src0 src1 Integer average of two source operands, rounding up. Store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] avg[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] avg[.cmod] (exec_size) reg reg reg [(pred)] avg[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = (src0.chan[n] + src1.chan[n] + 1) >> 1; // Use arithmetic shift right. } } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 151 Description: The avg instruction performs component-wise integer average of src0 and src1 and stores the results in dst. An integer average uses integer upward rounding. It is equivalent to increment one to the addition of src0 and src1 and then apply an arithmetic right shift to this intermediate value. 6.9 bfe – Bit Field Extract Opcode Instruction Description 24 (0x18) bfe dst src0 src1 src2 Extract a bit field defined by src0 and src1 from src2 and store in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type UD UD D D Format: [(pred)] bfe (exec_size) dst src0 src1 src2 Syntax: [(pred)] bfe (exec_size) reg reg reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD width = src0.chan[n][4:0]; UD offset = src1.chan[n][4:0]; if ( width == 0 ) { dst.chan[n] = 0x00000000; } else if ( (width + offset) < 32 ) { dst.chan[n] = src2.chan[n] << (32 - width - offset); if (src2 is signed) { dst.chan[n] = dst.chan[n] >> (32 - width); // pad sign bit of dst.chan } else { dst.chan[n] = dst.chan[n] >> (32 - width); // pad 0 } } else { if ( src2 is signed ) { dst.chan[n] = src2.chan[n] >> offset; // pad sign bit } else { dst.chan[n] = src2.chan[n] >> offset; // pad 0 } } } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 152 } Description: Component-wise extract a bit field from src2 using the bit field width from src0 and the bit field offset from src1. Store the extracted bit field value in the low bits of dst and sign extend (if D type) or zero extend (if UD type). The width and offset values are from the low five bits of src0 and src1 respectively, or src0 & 0x1f and src1 & 0x1f. If width is zero, the result is zero. If offset + width > 32 then the extracted bit field is bits offset to 31 of src2, extracting only 32 - offset bits, less than width as the bit field cannot extend past the MSB of the source value. Otherwise extract width bits extending from bit positions offset to offset + width - 1. Restrictions: No accumulator access, implicit or explicit. All three-source instructions have certain restrictions, described in Instruction Machine Formats. 6.9.1 bfi1 – Bit Field Insert 1 Opcode Instruction Description 25 (0x19) bfi1 dst src0 src1 Create a bit mask defined by src0 and src1 and store in dst. Pred Sat Cond Mod Src Mod Y N N N Src Types Dst Type UD UD D D Format: [(pred)] bfi1 (exec_size) dst src0 src1 Syntax: [(pred)] bfi1 (exec_size) reg reg reg [(pred)] bfi1 (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD width = src0.chan[n][4:0]; UD offset = src1.chan[n][4:0]; dst = ((1 << width) - 1) << offset; } } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 153 Description: The bfi1 instruction is the first instruction in a two-instruction macro for bfi (Bit Field Insert). The bfi1 instruction component-wise generates mask with control from src0 and src1 and stores the results in dst. The mask is used in the bfi2 instruction to generate the final result of bfi. Create a bit mask corresponding to the bit field width and offset in src0 and src1. Store the bit mask in dst. The mask has all bits in the bit field set to 1 and all other bits as 0. The width and offset values are from the low five bits of src0 and src1 respectively, or src0 & 0x1f and src1 & 0x1f. If width is zero, the result is zero. The bfi macro has four source operands: src0 - bit field width in low five bits, src1 - bit field offset/starting bit position in low five bits, src2 - bit field value to insert, using only the number of least significant bits given by width in src0, and src3 - overall value into which the bit field is inserted, providing all bits other than the inserted bits for the result value. bfi dst src0 src1 src2 src3 // Translates to these two instructions: bfi1 dst src0 src1 bfi2 dst dst src2 src3 Restrictions: No accumulator access, implicit or explicit. 6.10 bfi2 – Bit Field Insert 2 Opcode Instruction Description 26 (0x1A) bfi2 dst src0 src1 src2 Extract a bit field defined by src0 and src1 from src2 and store in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type UD UD D D Format: [(pred)] bfi2 (exec_size) dst src0 src1 src2 Syntax: [(pred)] bfi2 (exec_size) reg reg reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD offset = LZD(reverse(src0.chan[n]))-1; Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 154 // offset is the number of LSB zero bits below the bit mask which has all 1s. // width (implied by the logic) is the number of 1 bits in the mask value, which should be all 1s. dst.chan[n] = ((src1.chan[n] << offset) & src0.chan[n]) | (src2.chan[n] & ! src0.chan[n]); } Description: The bfi2 instruction is the second instruction in a two-instruction macro for bfi (Bit Field Insert). The bfi2 instruction component-wise performs the bitfield insert operation on src1 and src2 based on the mask in src0. Use the mask in src0 to take a bit field value from the low bits of src1 and combine it with the value from src2 (so src2 provides all bits other than those masked out and replaced by the bit field value). Store the result in dst. The bfi macro has four source operands: src0 - bit field width in low five bits, src1 - bit field offset/starting bit position in low five bits, src2 - bit field value to insert, using only the number of least significant bits given by width in src0, and src3 - overall value into which the bit field is inserted, providing all bits other than the inserted bits for the result value. bfi dst src0 src1 src2 src3 // Translates to these two instructions: bfi1 dst src0 src1 bfi2 dst dst src2 src3 Restrictions: No accumulator access, implicit or explicit. All three-source instructions have certain restrictions, described in Instruction Machine Formats. 6.11 bfrev – Reverse Bits Opcode Instruction Description 23 (0x17) bfrev dst src0 Reverse all bits in src0 and store in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type UD UD Format: [(pred)] bfrev (exec_size) dst src0 Syntax: [(pred)] bfrev (exec_size) reg reg [(pred)] bfrev (exec_size) reg imm32 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 155 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { for ( idx = 0; idx < 32; idx++ ) { dst.chan[n][idx] = src0.chan[n][31-idx]; } } } Description: The bfrev instruction component-wise reverses all the bits in src0 and stores the results in dst. Restrictions: No accumulator access, implicit or explicit. 6.12 brc – Branch Converging Opcode Instruction Description 35 (0x23) brc JIP UIP Redirect channel execution to the instruction referenced by UIP. Pred Sat Cond Mod Src Mod Y N N N Src Types Dst Type D Format: [(pred)] brc (exec_size) JIP UIP Syntax: [(pred)] brc (exec_size) imm16 imm16 [(pred)] brc (exec_size) reg32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if ( WrEn[n] ) { PcIP[n] = IP + UIP; } else { PcIP[n] = IP + 1; } } if ( all PcIP != IP + 1 ) { // for all channels Jump(IP + JIP); } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 156 Description: The brc instruction redirects the execution forward or backward to the instruction pointed by (current IP + offset). The jump will occur if all channels are branched away. UIP should reference the instruction where all channels are expected to come together. JIP should reference the end of the innermost conditional block. Immediate Offset Bits Description 31:16 UIP (Update Target Offset) The relative offset in 64-bit units if a jump is taken for the channel. Format = S15. 15:0 JIP (Jump Target Offset) The relative offset in 64-bit units if a jump is taken for the instruction. Format = S15. Register Offset Bits Description 31:16 UIP (Update Target Offset) The relative offset in 64-bit units if a jump is taken for the channel. Format = S15. 15:0 JIP (Jump Target Offset) The relative offset in 64-bit units if a jump is taken for the instruction. Format = S15. In the architecture binary, JIP and UIP are at location src1 when immediates and at location src0 when reg32, where reg32 is accessed as a scalar DWord containing both JIP and UIP. The null register must be used (for example, by the assembler) as dst. When offsets are immediate, src0 must be null. Restrictions: A brc instruction must use the Switch instruction option. Erratum: brc instructions cannot be used with offsets in registers, but only with immediate offsets. Erratum: brc instructions cannot be used within if-endif or if-else-endif conditional blocks. 6.13 brd – Branch Diverging Opcode Instruction Description 33 (0x21) brd JIP Redirect program execution to the instruction referenced by JIP. Pred Sat Cond Mod Src Mod Y N N N Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 157 Src Types Dst Type D Format: [(pred)] brd (exec_size) JIP Syntax: [(pred)] brd (exec_size) imm16 [(pred)] brd (exec_size) reg32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if ( WrEn[n] ) { PcIP[n] = IP + JIP; } else { PcIP[n] = IP + 1; } } if ( any PcIP == ExIP + JIP ) { // any channel Jump(ExIP + JIP); } Description: The brd instruction redirects the execution forward or backward to the instruction pointed by (current IP + offset). The jump will occur if any channels are branched away. Immediate Offset ] Bits Description 31:16 Reserved. MBZ. 15:0 JIP (Jump Target Offset) The relative offset in 64-bit units if a jump is taken for the instruction. Format = S15. Register Offset Bits Description 31:16 Reserved. MBZ. 15:0 JIP (Jump Target Offset) The relative offset in 64-bit units if a jump is taken for the instruction. Format = S15. In GEN binary, JIP is at location src1 when immediate and at location src0 when reg32, where reg32 is accessed as a scalar DWord. The null register must be used at dst locations. Restrictions: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 158 A brd instruction must use the Switch instruction option. Erratum: brd instructions cannot be used with offsets in registers, but only with immediate offsets. 6.14 break – Break Opcode Instruction Description 40 (0x28) break JIP UIP Terminate enabled execution channels and conditionally break out from the inner most loop. Pred Sat Cond Mod Src Mod Y N N N Format: [(pred)] break (exec_size) JIP UIP Syntax: [(pred)] break (exec_size) imm16 imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.channel[n] ) { PcIP[n] = IP + UIP; else { PcIP[n] = IP + 1; } } if ( PcIP != (IP + 1) ) { // all channels Jump(IP + JIP); } Description: The break instruction is used to early-out from the inner most loop, or early out from the inner most switch block. When used in a loop, upon execution, the break instruction terminates the loop for all execution channels enabled. If all the enabled channels hit the break instruction, jump to the instruction referenced by JIP. JIP should be the offset to the end of the inner most conditional or loop block, UIP should be the offset to the while instruction of the loop block. ]: The following table describes the two 16-bit instruction pointer offsets. Both the JIP and UIP are signed 16-bit numbers, added to IP pre-increment. In GEN binary, JIP and UIP are at location src1 and must be of type W (signed word integer). Relative Instruction Offsets ] Bits Description 31:16 UIP (Update Target Offset). The jump distance in number of eight-byte units if a jump is taken for the channel. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 159 Bits Description Format = S15. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. If SPF is ON, the UIP must be used to update IP; JIP is not used in this case. Restrictions: The execution size must be the same for the while, break, and cont instructions of the same code block. 6.15 call – Call Opcode Instruction Description 44 (0x2C) call dst JIP Subroutine call. Pred Sat Cond Mod Src Mod Y N N N Src Types Dst Type D, UD Format: [(pred)] call (exec_size) dst JIP Syntax: [(pred)] call (exec_size) reg imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if (WrEn.chan[n] ) { PcIP[n] = IP + JIP; CallMask[n] = 1; } else { PcIP[n] = IP + 1; CallMask[n] = 0; } } if ( PcIP[n] != (IP + 1) ) { // any channel jumped dst.chan[0] = IP + 1; dst.chan[1] = CallMask; Jump(IP + JIP); } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 160 Description: The call instruction jumps to a subroutine. It can be predicated or non-predicated. If non-predicated, all enabled channels jump to the subroutine. If predicated, only the channels enabled by PMask jump to the subroutine; the rest of the channels move to the next instruction after the call instruction. If none of the channels jump into the subroutine, the call instruction is treated as a nop. In case of a jump, the call instruction stores the return IP onto the first DWord of the destination register and stores the CallMask in the second DWord of the destination register. When SPF is on, the predication control must be scalar. The following table describes JIP, the jump offset, for. JIP must be a signed immediate operand. When a jump occurs, this value is added to IP pre-increment. Immediate Instruction Offset Bits Description 31:16 Reserved: MBZ 15:0 JIP (Jump Instruction Count). The jump distance in number of 64-bit units if a jump is taken for the instruction. Format = S15. Restrictions: The call instruction must have DWord source and destination type, and the destination must be QWord aligned. ] The source0 regioning control must be <2;2,1>. The execution size must be 2. Workaround: A call instruction before a send with EOT should:  Have no predication.  Should use {NoMask}.  Should specify for the destination any general register that is not part of the final send.  Should specify a JIP value referencing the send instruction that has EOT. Example: call (2) r1 0x2 {NoMask} send ... {EOT} Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 161 6.16 cbit – Count Bits Set Opcode Instruction Description 77 (0x4D) cbit dst src0 Count the number of bits set (1) in src0 and store that count in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type UB, UW, UD UD Format: [(pred)] cbit (exec_size) dst src0 Syntax: [(pred)] cbit (exec_size) reg reg [(pred)] cbit (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD cnt = 0; UD val = src0.chan[n]; while ( val ) { if ( val & 1 ) { cnt ++; } val = val >> 1; } dst.chan[n] = cnt; } } Description: The cbit instruction counts component-wise the total bits set in src0 and stores the resulting counts in dst. Restrictions: No accumulator access, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 162 6.17 cmp – Compare Opcode Instruction Description 16 (0x10) cmp.cmod dst src0 src1 Compare src0 and src1 as specified by the conditional modifier and store the resulting flags in dst and in the flag register. Pred Sat Cond Mod Src Mod Y N Y Y Src Types Dst Type *B, *W, *D *B, *W, *D *B, *W, *D F F F DF DF Format: [(pred)] cmp[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] cmp[.cmod] (exec_size) reg reg reg [(pred)] cmp[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { bitMask[n] = 0; if ( WrEn.chan[n] ) { results[n] = src0.chan[n] - src1.chan[n]; bitMask[n] = Condition(results[n]); dst.chan[n] = bitMask[n]; // All bits for dst channel } } flag# = bitMask; Description: The cmp instruction performs component-wise comparison of src0 and src1 and stores the results in the selected flag register and in dst. It takes component-wise subtraction of src0 and src1, evaluating the conditional code (excluding NS signal) based on the conditional modifier, and storing the conditional bits in bit-packed form in the destination flag register and all bits of dst channels. If the dst is not null, for the enabled channels, then all bits of the destination channel will contain the flag value for the channel. When the instruction operates on packed word format, one general register may store up to 16 such comparison results. In DWord format, one general register may store up to 8 results. A conditional modifier must be specified; the conditional modifier field cannot be 0000b. The comparison does not use the NS (NaN source) signals, as described in the Creating Conditional Flags section. Accordingly the conditional modifier should not be .u (unordered). For each enabled channel 0b or 1b is assigned to the appropriate flag bit and 0/all zeros or all ones (e.g, byte 0xFF, word 0xFFFF, DWord 0xFFFFFFFF) is assigned to dst. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 163 When any source type is floating-point, the cmp instruction obeys the rules described in the tables in the Floating Point Modes section of the Data Types chapter. Restrictions: Accumulator cannot be destination, implicit or explicit. The destination must be a general register or the null register. A SIMD16 instruction is not allowed for DWord data types. Use two SIMD8 instructions. If the destination is the null register, the {Switch} instruction option must be used. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 164 6.18 cmpn – Compare NaN Opcode Instruction Description 17 (0x11) cmpn.cmod dst src0 src1 Compare src0 and src1 with a special NaN comparison as specified by the conditional modifier and store the resulting flags in dst and in the flag register. Pred Sat Cond Mod Src Mod Y N Y Y Src Types Dst Type *B, *W, *D *B, *W, *D *B, *W, *D F F F DF DF Format: [(pred)] cmpn[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] cmpn[.cmod] (exec_size) reg reg reg [(pred)] cmpn[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { bitMask[n] = 0; if ( WrEn.chan[n] ) { results[n] = src0.chan[n] - src1.chan[n]; bitMask[n] = ConditionNaN(results[n]); dst.chan[n][0] = bitMask[n]; // All bits for dst channel } } flag# = bitMask; Description: The cmpn instruction performs component-wise special-NaN comparison of src0 and src1 and stores the results in the selected flag register and in dst. It takes component-wise subtraction of src0 and src1, evaluating the conditional signals including NS based on the conditional modifier, and storing the conditional flag bits in bit-packed form in the destination flag register and all bits of dst channels. If the dst is not null, for the enabled channels, then all bits of the destination channel will contain the flag value for the channel. When the instruction operates on packed word format, one general register may store up to 16 such comparison results. In DWord format, one general register may store up to 8 results. A conditional modifier must be specified; the conditional modifier field cannot be 0000b. More information about the conditional signals used is in the Creating Conditional Flags section. For each enabled channel 0b or 1b is assigned to the appropriate flag bit and 0/all zeros or all ones (e.g, byte 0xFF, word 0xFFFF, DWord 0xFFFFFFFF) is assigned to dst. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 165 This instruction is similar to cmp. The only difference is that if the second source operand src1 is a NaN, the result for any conditional modifier except .nz is true (see the Min/Max of Floating Point Numbers section for details). Restrictions: Accumulator cannot be destination, implicit or explicit. The destination must be a general register or the null register. ]: A SIMD16 instruction is not allowed for DWord data types. Use two SIMD8 instructions. ]: If the destination is the null register, the {Switch} instruction option must be used. 6.19 cont – Continue Opcode Instruction Description 41 (0x29) cont JIP UIP Temporarily disable enabled execution channels for the remainder of the inner most loop and conditionally jump to the last instruction (while) of the loop. Pred Sat Cond Mod Src Mod Y N N N Format: [(pred)] cont (exec_size) JIP UIP Syntax: :[(pred)] cont (exec_size) imm16 imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.channel[n] ) { if ( PMask[n] ) { // PMask is for all channels enabled for the cont instruction. PcIP[n] = IP + UIP; } else { PcIP[n] = IP + 1; } } } for ( n = exec_size; n < 32; n++ ) { PcIP[n] = IP + 1; } if ( PcIP != (IP + 1) ) { // all channels true Jump(IP + JIP); } Description: The cont instruction disables execution for the subset of channels for the remainder of the current loop iteration. Channels remain disabled until right before the while instuction or right before the condition check code block for the while instruction. If all enabled channels hit this instruction, jump to the instruction referenced by JIP where execution continues. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 166 UIP should always reference the loop's associated while instruction. JIP should point to the last instruction of the inner most conditional block if the cont instruction is inside a conditional block. In case of the break instruction directly under the loop, the JIP and the UIP are the same. The following table describes the two 16-bit instruction pointer offsets. Both the JIP and UIP are signed 16-bit numbers, added to IP pre-increment. In GEN binary, JIP and UIP are at location src1 and must be of type W (signed word integer). Relative Instruction Offsets Bits Description 31:16 UIP (Update Target Offset). The jump distance in number of eight-byte units if a jump is taken for the channel. Format = S15. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. 6.20 dp2 – Dot Product 2 Opcode Instruction Description 87 (0x57) dp2 dst src0 src1 Perform two-wide dot product using the first two elements of each four-tuple from src0 and src1 and store the four-wide replicated results in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type F F Format: [(pred)] dp2[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] dp2[.cmod] (exec_size) reg reg reg [(pred)] dp2[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 4 ) { fTmp = src0.chan[n] * src1.chan[n] + src0.chan[n+1] * src1.chan[n+1]; if ( WrEn.chan[n] ) dst.chan[n] = fTmp; if ( WrEn.chan[n+1] ) dst.chan[n+1] = fTmp; if ( WrEn.chan[n+2] ) dst.chan[n+2] = fTmp; if ( WrEn.chan[n+3] ) dst.chan[n+3] = fTmp; } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 167 Description: The dp2 instruction performs a two-wide dot product on four-tuple vector basis and storing the same scalar result per four tuple to all four channels in dst. This instruction is similar to dp4 except that every third and fourth element of src0 (post-source-swizzle if present) are not involved in the computation. The dot product of two vectors of equal length is the sum of the products of each pair of corresponding elements. The dp4 instruction includes all four elements of each vector in the dot product. The dp3 instruction includes the first three elements of each vector in the dot product. Restrictions: Execution size cannot be less than 4. Horizontal strides must be 1. Source operands cannot be accumulators. 6.21 dp3 – Dot Product 3 Opcode Instruction Description 86 (0x56) dp3 dst src0 src1 Perform three-wide dot product using the first three elements of each four- tuple from src0 and src1 and store the four-wide replicated results in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type F F Format: [(pred)] dp3[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] dp3[.cmod] (exec_size) reg reg reg [(pred)] dp3[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 4 ) { fTmp = src0.chan[n] * src1.chan[n] + src0.chan[n+1] * src1.chan[n+1]; + src0.chan[n+2] * src1.chan[n+2]; if ( WrEn.chan[n] ) dst.chan[n] = fTmp; if ( WrEn.chan[n+1] ) dst.chan[n+1] = fTmp; if ( WrEn.chan[n+2] ) dst.chan[n+2] = fTmp; if ( WrEn.chan[n+3] ) dst.chan[n+3] = fTmp; } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 168 Description: The dp3 instruction performs a three-wide dot product on four-tuple vector basis and storing the same scalar result per four tuple to all four channels in dst. This instruction is similar to dp4 except that every fourth element of src0 (post-source-swizzle if present) is not involved in the computation. The dot product of two vectors of equal length is the sum of the products of each pair of corresponding elements. The dp4 instruction includes all four elements of each vector in the dot product. The dp2 instruction includes the first two elements of each vector in the dot product. Restrictions: Execution size cannot be less than 4. Horizontal strides must be 1. Source operands cannot be accumulators. 6.22 dp4 – Dot Product 4 Opcode Instruction Description 84 (0x54) dp4 dst src0 src1 Perform four-wide dot product of src0 and src1 and store the four-wide replicated results in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type F F Format: [(pred)] dp4[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] dp4[.cmod] (exec_size) reg reg reg [(pred)] dp4[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 4 ) { fTmp = src0.chan[n] * src1.chan[n] + src0.chan[n+1] * src1.chan[n+1] + src0.chan[n+2] * src1.chan[n+2] + src0.chan[n+3] * src1.chan[n+3]; if ( WrEn.chan[n] ) dst.chan[n] = fTmp; if ( WrEn.chan[n+1] ) dst.chan[n+1] = fTmp; if ( WrEn.chan[n+2] ) dst.chan[n+2] = fTmp; if ( WrEn.chan[n+3] ) dst.chan[n+3] = fTmp; } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 169 Description: The dp4 instruction performs a four-wide dot product on four-tuple vector basis and storing the same scalar result per four tuple to all four channels in dst. The dot product of two vectors of equal length is the sum of the products of each pair of corresponding elements. Restrictions: Execution size cannot be less than 4. Horizontal strides must be 1. Source operands cannot be accumulators. 6.23 dph – Dot Product Homogeneous Opcode Instruction Description 85 (0x55) dph dst src0 src1 Perform four-wide homogeneous dot product of src0 and src1 and store the four-wide replicated results in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type F F Format: [(pred)] dph[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] dph[.cmod] (exec_size) reg reg reg [(pred)] dph[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 4 ) { fTmp = src0.chan[n] * src1.chan[n] + src0.chan[n+1] * src1.chan[n+1] + src0.chan[n+2] * src1.chan[n+2] + src1.chan[n+3]; // Use 1.0f in place of src0.chan[n+3]. if ( WrEn.chan[n] ) dst.chan[n] = fTmp; if ( WrEn.chan[n+1] ) dst.chan[n+1] = fTmp; if ( WrEn.chan[n+2] ) dst.chan[n+2] = fTmp; if ( WrEn.chan[n+3] ) dst.chan[n+3] = fTmp; } Description: The dph instruction performs a four-wide homogeneous dot product on four-tuple vector basis and storing the same scalar result per four tuple to all four channels in dst. This instruction is similar to dp4 except that every fourth element of src0 (post-source-swizzle if present) is forced to 1.0f. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 170 Use the dp4 instruction to do a four-wide dot product that includes all elements of src0 and src1. Restrictions: Execution size cannot be less than 4. Horizontal strides must be 1. Source operands cannot be accumulators. 6.24 else – Else Opcode Instruction Description 36 (0x24) else JIP An optional statement within an if/else/endif block of code. Pred Sat Cond Mod Src Mod N N N N Format: else (exec_size) JIP Syntax: else (exec_size) imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if ( WrEn.channel[n] ) { PcIP[n] = IP + JIP; } } if ( PcIP != ( IP + 1) ) { // for all channels Jump(IP + JIP); } Description: The else instruction is an optional statement within an if/else/endif block of code. It restricts execution within the else/endif portion to the opposite set of channels enabled under the if/else portion. Channels which were inactive before entering the if/endif block remain inactive throughout the entire block. All enabled channels upon arriving at the else instruction are redirected to the matching endif. If all channels are redirected (by else or before else), a relative jump is performed to the location specified by JIP. The jump target should be the the matching endif instruction for that conditional block. The following table describes the 16-bit JIP. In GEN binary, JIP is at location src1 and must be of type W (signed word integer). JIP must be an immediate operand, it is a signed 16-bit number and is intended to be forward referencing. This value is added to IP pre-increment. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 171 Relative Instruction Offset Bits Description 31:16 Reserved: MBZ. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. Restrictions: Predication is not allowed. The execution size must be the same for the if, else, and endif instructions of the same code block. 6.25 endif – End If Opcode Instruction Description 37 (0x25) endif JIP Restore execution to the channels that were active prior to the if/else/endif block. Jump to next hop point if all channels are disabled. Pred Sat Cond Mod Src Mod N N N N Format: endif JIP Syntax: endif (exec_size) imm16 Pseudocode: Evaluate(WrEn); if ( WrEn == 0 ) { // all channels false Jump(IP + JIP); } Description: The endif instruction terminates an if/else/endif block of code. It restores execution to the channels that were active prior to the if/else/endif block. The endif instruction is also used to hop out of nested conditionals by jumping to the end of the next outer conditional block when all channels are disabled. The following table describes the 16-bit JIP. In GEN binary, JIP is at location src1 and must be of type W (signed word integer). JIP must be an immediate operand, it is a signed 16-bit number. This value is added to IP pre-increment. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 172 Relative Instruction Offset Bits Description 31:16 Reserved: MBZ. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. Restrictions: Predication is not allowed. The execution size must be the same for the if, else, and endif instructions of the same code block. 6.26 f16to32 – Half Precision Float to Single Precision Float Opcode Instruction Description 20 (0x14) f16to32 dst src0 Convert a 16-bit half precision floating-point value to a 32-bit Float value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type W F Format: [(pred)] f16to32[.cmod] (exec_size) dst src0 Syntax: [(pred)] f16to32[.cmod] (exec_size) reg reg [(pred)] f16to32[.cmod] (exec_size) reg imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = convert half precision float to single precision float(src0.chan[n]); } } Description: The f16to32 instruction converts the half precision float in src0 to single precision float and storing in dst. Because this instruction does not have a 16-bit floating-point type, the source data type must be Word (W). The destination type must be F (Float). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 173 Restrictions: The FP Mode (Single Precision Floating Point Mode in cr0) must be IEEE mode. No accumulator access, implicit or explicit. Floating-Point Conversion in IEEE mode Half Precision Float to Single Precision Float ] Half Precision Float Single Precision Float -inf -inf -finite -finite -denorm -finite -0 -0 +0 +0 +denorm +finite +finite +finite +inf +inf NaN NaN 6.27 f32to16 – Single Precision Float to Half Precision Float Opcode Instruction Description 19 (0x13) f32to16 dst src0 Convert a 32-bit Float value to a 16-bit half precision floating-point value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F W Format: [(pred)] f32to16[.cmod] (exec_size) dst src0 Syntax: [(pred)] f32to16[.cmod] (exec_size) reg reg [(pred)] f32to16[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = convert single precision float to half precision float(src0.chan[n]); } } Description: The f32to16 instruction converts the single precision float in src0 to half precision float and storing in the lower word of each channel in dst. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 174 Because this instruction does not have a 16-bit floating-point type, the destination data type must be Word (W). Restrictions: The destination must be DWord-aligned and specify a horizontal stride (HorzStride) of 2. The 16-bit result is stored in the lower word of each destination channel and the upper word is not modified. The FP Mode (Single Precision Floating Point Mode in cr0) must be IEEE mode. No accumulator access, implicit or explicit. Floating-Point Conversion in IEEE mode Single Precision Float to Half Precision Float ] Single Precision Float Half Precision Float -inf -inf -finite -finite/-denorm/-0 -denorm -0 -0 -0 +0 +0 +denorm +0 +finite +finite/+denorm/+0 +inf +inf NaN NaN 6.28 fbh – Find First Bit from MSB Side Opcode Instruction Description 75 (0x4B) fbh dst src0 Find the first significant bit searching from the high bits in src0 and store the result in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type D, UD UD Format: [(pred)] fbh (exec_size) dst src0 Syntax: [(pred)] fbh (exec_size) reg reg [(pred)] fbh (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD cnt = 0; if ( src0 is unsigned ) { UD udScalar = src0.chan[n]; while ( (udScalar & (1 << 31)) == 0 && cnt != 32 ) { Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 175 cnt ++; udScalar = udScalar << 1; } if ( src0.chan[n] == 0x00000000 ) { dst.chan[n] = 0xFFFFFFFF; } else { dst.chan[n] = cnt; } } else { // src0 is signed. D dScalar = src0.chan[n]; bit cval = dScalar[31]; while ((dScalar & (1 << 31)) == cval && cnt != 32 ) { cnt ++; dScalar = dScalar << 1; } if ( (src0.chan[n] == 0xFFFFFFFF) || (src0.chan[n] == 0x00000000) ) { dst.chan[n] = 0xFFFFFFFF; } else { dst.chan[n] = cnt; } } } } Description: If src0 is unsigned, the fbh instruction counts component-wise the leading zeros from src0 and stores the resulting counts in dst. If src0 is signed and positive, the fbh instruction counts component-wise the leading zeros from src0 and stores the resulting counts in dst. If src0 is signed and negative, the fbh instruction counts component-wise the leading ones from src0 and stores the resulting counts in dst. Special Cases: If src0 is zero, store 0xFFFFFFFF in dst. If src0 is signed and is -1 (0xFFFFFFFF), store 0xFFFFFFFF in dst. Restrictions: No accumulator access, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 176 6.29 fbl – Find First Bit from LSB Side Opcode Instruction Description 76 (0x4C) fbl dst src0 Find the first 1 bit searching from the low bits in src0 and store the result in dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type UD UD Format: [(pred)] fbl (exec_size) dst src0 Syntax: [(pred)] fbl (exec_size) reg reg [(pred)] fbl (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD cnt = 0; UD udScalar = src0.chan[n]; while ( (udScalar & 1) == 0 && cnt != 32 ) { cnt ++; udScalar = udScalar >> 1; } if ( src0.chan[n] == 0x00000000 ) { dst.chan[n] = 0xFFFFFFFF; } else { dst.chan[n] = cnt; } } } Description: The fbl instruction counts component-wise the number of LSB 0 bits before the first 1 bit in src0, storing that number in dst. If src0 contains no 1 bits, store 0xFFFFFFFF in dst. Restrictions: No accumulator access, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 177 6.30 frc – Fraction Opcode Instruction Description 67 (0x43) frc dst src0 Truncate toward minus infinity fraction part of src0 and store in dst. Pred Sat Cond Mod Src Mod Y N Y Y Src Type Dst Type F F Format: [(pred)] frc[.cmod] (exec_size) dst src0 Syntax: [(pred)] frc[.cmod] (exec_size) reg reg [(pred)] frc[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] - floor(src0.chan[n]); } } Description: The frc instruction computes, component-wise, the truncate-to-minus-infinity fractional values of src0 and stores the results in dst. The results, in the range of [0.0, 1.0], are the fractional portion of the source data. The result is in the range [0.0, 1.0] irrespective of the rounding mode. Floating-point fraction computation follows the rules in the following tables, based on the current floating- point mode. Floating-Point Fraction Computation in IEEE mode src0 -inf -finite -denorm -0 +0 +denorm +finite +inf NaN dst NaN * +0 +0 +0 +0 * NaN NaN Notes: * Result is in the range [+0.0, 1.0), not including 1.0. Floating-Point Fraction Computation in ALT mode src0 -fmax -finite -denorm -0 +0 +denorm +finite +fmax ** dst +0 * +0 +0 +0 +0 * +0 Notes: * Result is in the range [+0.0, 1.0), not including 1.0. ** Result is undefined if src0 is {–inf, +inf, or NaN}. Restrictions: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 178 Erratum: When the Rounding Mode in cr0.0 is Round Down, the result from frc must be negated to bring it into the range [0.0, 1.0) not including 1.0. Workaround: When the Rounding Mode in cr0.0 is not Round Down, the result from frc must be followed by compare and select instructions to avoid a result of 1.0. Those latter instructions must use the :ud type. For example: cmp.ne.f0.0 null r4:ud 0x3f800000:ud (f0.0)sel r5:f r4:ud 0x3f7fffff:ud 6.31 halt – Halt Opcode Instruction Description 42 (0x2A) halt JIP UIP Temporarily suspend execution for all enabled execution channels. Pred Sat Cond Mod Src Mod Y N N N Format: [(pred)] halt (exec_size) JIP UIP Syntax: [(pred)] halt (exec_size) imm16 imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if ( WrEn.channel[n] ) { PcIP[n] = IP + UIP; else { PcIP[n] = IP + 1; } } if ( PcIP != (IP + 1) ) { // for all channels Jump(IP + JIP); } Description: The halt instruction temporarily suspends execution for all enabled compute channels. Upon execution, the enabled channels are sent to the instruction at (IP + UIP), if all channels are enabled at HALT, jump to the instruction at (IP + JIP). If the halt instruction is not inside any conditional code block, the values of JIP and UIP should be the same. If the halt instruction is inside a conditional code block, the UIP should be the end of the program and the JIP should be the end of the inner most conditional code block. The following table describes the two 16-bit instruction pointer offsets. Both the JIP and UIP are signed 16-bit numbers, added to IP pre-increment. In GEN binary, JIP and UIP are at location src1 and must be of type W (signed word integer). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 179 Relative Instruction Offsets Bits Description 31:16 UIP (Update Target Offset). The jump distance in number of eight-byte units if a jump is taken for the channel. Format = S15. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. If SPF is ON, the UIP must be used to update IP; JIP is not used in this case. Restrictions: dst and src0 must be NULL. Workaround:: When SPF is ON, the JIP must point to a nop instruction. 6.32 if – If Opcode Instruction Description 34 (0x22) if JIP UIP Indicate the start of an if/else/endif block of code. Pred Sat Cond Mod Src Mod Y N N N Format: [(pred)] if (exec_size) JIP UIP Syntax: [(pred)] if (exec_size) imm16 imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if ( WrEn.channel[n] == 0 ) { PcIP[n] = IP + JIP; } else { PcIP[n] = IP + 1; } } if ( PcIP != (IP + 1) ) { // for all channels Jump(IP + JIP); } Description: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 180 An if instruction starts an if/endif or an if/else/endif block of code. It restricts execution within the conditional block to only those channels that were enabled via the predicate control. Each if instruction must have a matching endif instruction and may have up to one matching else instruction before the matching endif. If all channels are inactive (for the if/endif or if/else/endif block), a jump is performed to the instruction referenced by JIP. This jump must be to right after the matching else instruction when present, or otherwise to the matching endif instruction of the conditional block. The following table describes the two 16-bit instruction pointer offsets. Both the JIP and UIP are signed 16-bit numbers, added to IP pre-increment. In GEN binary, JIP and UIP are at location src1 and must be of type W (signed word integer). Relative Instruction Offsets Bits Description 31:16 UIP (Update Target Offset). The jump distance in number of eight-byte units if a jump is taken for the channel. Format = S15. 15:0 JIP (Jump Target Offset). The jump distance in number of eight-byte units if a jump is taken for the instruction. Format = S15. If SPF is ON, the UIP must be used to update IP; JIP is not used in this case. Restrictions: The execution size must be the same for the if, else, and endif instructions of the same code block. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 181 6.33 illegal – Illegal Opcode Instruction Description 0 (0x0) illegal Signal an illegal opcode exception, possibly transferring to the System Routine. If the exception is disabled, perform no operation. Pred Sat Cond Mod Src Mod N N N N Format: illegal Syntax: illegal Pseudocode: { Set the Illegal Opcode Exception Status bit in cr0.1. if ( Illegal Opcode Exception Enable is set in cr0.1 ) { Transfer control to the System Routine (return address to AIP, IP = SIP). } } Description: The Illegal Opcode Exception Enable flag in cr0.1 is normally set so the normal processing of an illegal opcode is to transfer control to the System Routine. Instruction dispatch treats any unused 8-bit opcode (including bit 7 of the instruction, reserved for future opcode expansion) as if it is the illegal opcode. The illegal opcode is zero because that byte value is more likely than most to be read via a wayward instruction pointer. The illegal instruction is an instruction only in the same way that a NULL pointer in software is a pointer. Both are special values indicating invalid instances. Restrictions: The illegal instruction takes no instruction options. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 182 6.34 jmpi – Jump Indexed Opcode Instruction Description 32 (0x20) jmpi index Redirect program execution based on an index relative to the post- incremented instruction pointer. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type D Format: [(pred)] jmpi (1) index {NoMask} Syntax: [(pred)] jmpi (1) reg32 {NoMask} [(pred)] jmpi (1) imm32 {NoMask} Pseudocode: Evaluate(WrEn); if ( WrEn != 0 ) { Jump(IP + 1 + index ); // IP + 1 is a pseudocode idiom for the IP of the following instruction. } Description: The jmpi instruction redirects program execution to an index offset relative to the post-incremented instruction pointer. The index is a signed integer value, with positive or zero integers for forward jumps, and negative integers for backward jumps. Note: Unlike other flow control instructions, the offset used by jmpi is relative to the incremented instruction pointer rather than the IP value for the instruction itself. In GEN binary, index is at location src1. The ip register must be put (for example, by the assembler) at the dst and src0 locations. Predication is allowed to provide conditional jump with a scalar condition. As the execution size is 1, the first channel of PMASK (flags post prediction control and negate) is used to determine whether the jump is taken or not. If the condition is false, the jump is not taken and execution continues with the next instruction. Index Bits Description 31:16 Reserved: MBZ 15:0 index (Jump Index) This field specifies the jump distance in number of 64-bit units if a jump is taken for the instruction. Format = S15. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 183 Restrictions: The execution size must be 1. The {NoMask} instruction option must be specified. The index data type must be D (Signed DWord Integer). Programming Notes: An index of 0 does nothing, continuing execution with the next instruction. An index of -2 (if the jmpi instruction is in native format) or -1 (if the jmpi instruction is in compact format) is an infinite loop on the jmpi instruction. 6.35 line – Line Opcode Instruction Description 89 (0x59) line dst src0 src1 Compute a line equation (v = p * u + q) of src0 and src1 and store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type F F Format: [(pred)] line[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] line[.cmod] (exec_size) reg reg reg [(pred)] line[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { dwP = src0.RegNum.SubRegNum[bits4:2]; // A DWord-aligned scalar. dwQ = src0.RegNum.(SubRegNum[bit4] | 0x8); // Fourth component. if ( WrEn.chan[n] ) { dst.chan[n] = dwP * src1.chan[n] + dwQ; } } Description: The line instruction computes a component-wise line equation (v = p * u + q where u, v are vectors and p, q are scalars) of src0 and src1 and stores the results in dst. src1 is the input vector u. src0 provides input scalars p and q, where p is the scalar value based on the region description of src0 and q is the scalar value implied from src0 region. Specifically, q is the fourth component of the 4-tuple (128-bit aligned) that p belongs to. Restrictions: This is a specialized instruction that only supports an execution size (ExecSize) of 8 or 16. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 184 The src0 region must be a replicated scalar (with HorzStride == VertStride == 0). src0 must specify .0 or .4 as the subregister number, corresponding to a subregister byte offset of 0 or 16. Source operands cannot be accumulators. 6.36 lrp – Linear Interpolation Opcode Instruction Description 92 (0x5c) lrp dst src0 src1 src2 Compute the linear interpolation equation (w = u*x + v*(1 - x)) of vectors (x, u, v) from src0, src1, and src2, storing the results in dst. Pred Sat Cond Mod Src Mod Y N Y Y Src Type Dst Type F F Format: [(pred)] lrp[.cmod] (exec_size) dst src0 src1 src2 Syntax: [(pred)] lrp[.cmod] (exec_size) reg reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src1.chan[n] * src0.chan[n] + src2.chan[n] * (1.0 – src0.chan[n]); } } Description: The lrp instruction takes component-wise multiplication of src0 and src1, and adds the result to the component-wise multiplication of src2 and (1 - src0), and then stores the final results in dst. Restrictions: The vertical stride (VertStride) is overloaded to 4 in HW for 3-source instructions. The overflow conditional modifier (.o) is not allowed. No explicit accumulator access because this is a three-source instruction. AccWrEn is allowed for implicitly updating the accumulator. All three-source instructions have certain restrictions, described in Instruction Machine Formats. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 185 6.37 lzd – Leading Zero Detection Opcode Instruction Description 74 (0x4A) lzd dst src0 Count the number of leading 0 bits (from MSB) in src0 and store that count in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type D, UD UD Format: [(pred)] lzd[.cmod] (exec_size) dst src0 Syntax: [(pred)] lzd[.cmod] (exec_size) reg reg [(pred)] lzd[.cmod] (exec_size) reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { UD udScalar = src0.chan[n]; UD cnt = 0; while ( (udScalar & (1 << 31)) == 0 && cnt != 32 ) { cnt ++; udScalar = udScalar << 1; } dst.chan[n] = cnt; } } Description: The lzd instruction counts component-wise the leading zeros from src0 and stores the resulting counts in dst. If src0 is zero, store 32 in dst. Restrictions: If the source is signed, the abs source modifier must be used to convert any negative source value to a positive value. Accumulator cannot be destination, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 186 6.38 mac – Multiply Accumulate Opcode Instruction Description 72 (0x48) mac dst src0 src1 Multiply src0 and src1, add to accumulator, and store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type *B, *W *B, *W, *D F F DF DF Format: [(pred)] mac[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] mac[.cmod] (exec_size) reg reg reg [(pred)] mac[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] * src1.chan[n] + acc0.chan[n]; } } Description: The mac instruction takes component-wise multiplication of src0 and src1, adds the results with the corresponding accumulator values, and then stores the final results in dst. Restrictions: Accumulator is an implicit source and thus cannot be an explicit source operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 187 6.39 mach – Multiply Accumulate High Opcode Instruction Description 73 (0x49) mach dst src0 src1 Multiply the upper word of src0 (masking off the lower word) times src1, adding the 64-bit product to the 64-bit accumulator value, storing the 64-bit result in the accumulator and storing the high DWord of the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Src Types Dst Type D D UD UD Format: [(pred)] mach[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] mach[.cmod] (exec_size) reg reg reg [(pred)] mach[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { acc.chan[n][63:0] = (src0.chan[n][31:16] * src1.chan[n][31:0]) << 16 + acc.chan[n][63:0]; if ( WrEn.chan[n] ) { dst.chan[n][31:0] = acc.chan[n][63:32]; } } Description: The mach instruction performs DWord integer multiply-accumulate operation and outputs the high DWord (bits 63:32). For each enabled channel, this instruction multiplies the DWord in src1 with the high word of the DWord in src0, left shifts the result by 16 bits, adds it with the corresponding accumulator values, and keeps the whole 64-bit result in the accumulator. It then stores the high DWord (bits 63:32) of the results in dst. This instruction is intended to be used to emulate 32-bit DWord integer multiplication by using the large number of bits available in the accumulator. For example, the following four instructions perform vector multiplication of two 32-bit signed integer sources from r2 and r3 and store the resulting vectors with the high 32 bits in r5 and the low 32 bits in r6. mul (8) acc0:d r2.0<8;8,1>:d r3.0<8;8,1>:d //All channels must be enabled mach (8) rTemp<1>:d r2.0<8;8,1>:d r3.0<8;8,1>:d //All channels must be enabled mov (8) r5.0<1>:d rTemp<8;8,1>:d // High 32 bits mov (8) r6.0<1>:d acc0:d // Low 32 bits Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 188 The mul and mach instructions must have all channels enabled. The first mov should have channel enable from the destHI of IMUL, the second mov should have the channel enable from the destLO of IMUL. As mach is used to generate part of the 64-bit DWord integer results, saturation modifier should not be used. In fact, saturation modifier should not be used for any of these four instructions. Source and destination operands must be DWord integers. Source and destination must be of the same type, signed integer or unsigned integer. If dst is UD, src0 and src1 may be UD and/or D. However, if any of src0 and src1 is D, source modifier (abs) must be present to convert it to match with dst. If dst is D, src0 and src1 must also be D. They cannot be UD as it may cause unexpected overflow because the computed results are limited to 64 bits. Restrictions: Accumulator is an implicit source and thus cannot be an explicit source operand. AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. 6.40 mad – Multiply Add Opcode Instruction Description 91 (0x5B) mad dst src0 src1 src2 Add src1 times src2 to src0 and store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F F DF DF Format: [(pred)] mad[.cmod] (exec_size) dst src0 src1 src2 Syntax: [(pred)] mad[.cmod] (exec_size) reg reg reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src1.chan[n] * src2.chan[n] + src0.chan[n]; } } Description: The mad instruction takes component-wise multiplication of src1 and src2, adds the results with the corresponding src0 values, and then stores the final results in dst. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 189 Restrictions: No explicit accumulator access because this is a three-source instruction. AccWrEn is allowed for implicitly updating the accumulator. All three-source instructions have certain restrictions, described in Instruction Machine Formats. 6.41 math – Extended Math Function Opcode Instruction Description 56 (0x38) math dst src0 src1 Component-wise extended math function on src0 (and src1) to dst based on the . Src Types Dst Type Pred Sat Cond Mod Src Mod Y Y F F Y Y D D Y Y UD UD Format: [(pred)] math (exec_size) dst src0 src1 Syntax: [(pred)] math (exec_size) reg reg reg imm4 Pseudocode: Evaluate(WrEn); for (n = 0; n < exec_size; n++) { if (WrEn.channel[n] == 1) { switch FC[3:0] { case 1h: dst.channel[n] = rcp(src0.channel[n]); case 2h: dst.channel[n] = log(src0.channel[n]); case 3h: dst.channel[n] = exp(src0.channel[n]); case 4h: dst.channel[n] = sqrt(src0.channel[n]); case 5h: dst.channel[n] = rsq(src0.channel[n]); case 6h: dst.channel[n] = sin(src0.channel[n]); case 7h: dst.channel[n] = cos(src0.channel[n]); case 9h: // src0 / src1 dst.channel[n] = fdiv(src0.channel[n], src1.channel[n]); case Ah: dst.channel[n] = pow(src0.channel[n], src1/channel[n]); case Bh: // src0 / src1 idiv(src0.channel[n], src1.channel[n]); dst.channel[n] = quotient; dst+1.channel[n] = remainder; case Ch: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 190 idiv(src0.channel[n], src1.channel[n]); dst.channel[n] = quotient; case Dh: idiv(src0.channel[n], src1.channel[n]); dst.channel[n] = remainder; } } } Description: The math instruction performs extended math function on the components in src0, or src0 and src1, and write the output to the channels of dst. The type of extended math function are based on the FC[3:0] encoding in the table below. Function Control[3:0] Description [3:0] Function Description: 0h: Reserved 1h: INV (reciprocal) 2h: LOG 3h: EXP 4h: SQRT 5h: RSQ 6h: SIN 7h: COS 8h: Reserved 9h: FDIV Ah: POW Bh: INT DIV – return quotient and remainder Ch: INT DIV – return quotient only Dh: INT DIV – return remainder Eh: Reserved Fh: Reserved Restrictions: No accumulator access, implicit or explicit. The math instruction must use GRF registers as source(s) and destination. The math instruction does not support indirect addressing modes. The only supported rounding mode for math instruction is Round to Nearest Even. For INTDIV with both quotient and remainder, the second destination register is implied from the first destination register with “+1” to get the register number. Mixed DW and UD sources are not allowed for the INT DIV function. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 191 INT DIV function does not support SIMD16. The FDIV function is not supported in ALT_MODE. 6.41.1 INV - Inverse Precision:1 ULP Src-> +inf +0 / +Denorm - 0 / -Denorm -inf NaN Dest – IEEE mode +0 +inf -inf -0 NaN Dest – ALT mode +fmax -fmax NaN 6.41.2 LOG – Logarithm Precision: DirectX 10 and below If src0 is [0.5..2], absolute error must be no more than 2-21. If src0 is (0..0.5) or (2..+INF], relative error must be no more than 2-21 Note:In ALT mode log is computed as Log2 (abs (src0)) Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode +inf -inf -inf NaN NaN NaN Dest – ALT mode -fmax -fmax +F NaN 6.41.3 EXP - Exponent Precision: DirectX 10 Relative error <= 3 ULP Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode +inf 1 1 0 +F NaN Dest – ALT mode 1 1 +F NaN 6.41.4 SQRT Precision: DirectX 10 (and below) Relative error <= 1 ULP Notes:In ALT mode SQRT is computed as SQRT(abs (src0)) Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode +inf 0 -0 NaN NaN NaN Dest – ALT mode 0 0 +F NaN Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 192 6.41.5 RSQ Precision: DirectX 10 and below Relative error <= 3 ULP Notes:In ALT mode RSQ is computed as RSQ(abs (src0)) Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode +0 +inf -inf NaN NaN NaN Dest – ALT mode +fmax +fmax +F NaN 6.41.6 POW Precision: POWR, POWN is not supported in hardware. IEEE Mode: Src0-> Src1 abs(F > 1) abs(F < 1) abs(+F = = 1) +inf +0 / +Denorm -Denorm / -0 -inf NaN +inf +inf 0 NaN +inf 0 0 +inf NaN +0 / Denorm 1 1 1 NaN NaN NaN NaN NaN -0 / Denorm 1 1 1 NaN NaN NaN NaN NaN -inf 0 +inf NaN 0 +inf +inf 0 NaN -F +F +F +F 0 +inf +inf 0 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN +F +F +inf 0 0 NaN NaN ALT Mode: Src0-> Src1 +F +inf +0 / +Denorm -0 / -Denorm -inf -F NaN +inf +0 / Denorm 1 1 1 1 NaN -0 / Denorm 1 1 1 1 NaN -inf -F +F +fmax +fmax +F NaN NaN NaN NaN NaN NaN +F +F 0 0 +F NaN Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 193 6.41.7 SIN Precision: DirectX 10 and below Absolute error <= 0.0008 for the range of +/- 100* pi Outside of the above range the function will remain periodic, producing values between -1 and 1. However, the period of SIN is determined by the internal representation of Pi, meaning that as the magnitude of input increases the absolute error will, in general, also increase. Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode NaN +0 -0 NaN -1 to 1 NaN Dest – ALT mode +0 -0 -1 to 1 NaN 6.41.8 COS Precision: DirectX 10 and below: Absolute error <= 0.0008 for the range of +/- 100* pi Outside of the above range the function will remain periodic, producing values between -1 and 1. However, the period of COS is determined by the internal representation of Pi, meaning that as the magnitude of input increases the absolute error will, in general, also increase. Src-> +inf +0 / +Denorm -0 / -Denorm -inf -F NaN Dest – IEEE mode NaN +0 -0 NaN -1 to 1 NaN Dest – ALT mode +1 +1 -1 to 1 NaN 6.41.9 INT DIV Precision:32-bit integer For signed inputs, INT DIV behavior is illustrated by the table below: Inputs: Numerator + + - - Denominator + - + - Outputs: Quotient + - - + Remainder + + - - Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 194 6.41.10 mov – Move Opcode Instruction Description 1 (0x01) mov dst src0 Copy the value from src0 to dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type *B, *W, *D *B, *W, *D *B, *W, *D F F *B, *W, *D F F *W, *D DF F DF DF *W, *D DF F DF DF Format: [(pred)] mov[.cmod] (exec_size) dst src0 Syntax: [(pred)] mov[.cmod] (exec_size) reg reg [(pred)] mov[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n]; } } Description: The mov instruction moves the components in src0 into the channels of dst. If src0 and dst are of different types, format conversion is performed. If src0 is a scalar immediate, the immediate value is loaded into enabled channels of dst. A mov with the same source and destination type, no source modifier, and no saturation is a raw move. A packed byte destination region (B or UB type with HorzStride == 1 and ExecSize > 1) can only be written using raw move. Restrictions: Raw move is not supported for Float values in ALT mode if any values are infinities or NaNs. An accumulator can be a source or destination operand but not both. If the source type and destination type differ, conditional modifiers are not allowed. Programming Notes: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 195 There is no direct conversion from B/UB to DF or DF to B/UB. Use two instructions and a word or DWord intermediate type. 6.42 6movi – Move Indexed Opcode Instruction Description 3 (0x3) movi dst src0 Fast indexed move from src0 to dst. Pred Sat Cond Mod Src Mod Y Y N Y Generation Src Type Dst Type B B UB UB W W UW UW D D UD UD F F Note: As shown in the table, the source and destination type must be the same. Format: [(pred)] movi[.cmod] (exec_size) dst src0 Syntax: [(pred)] movi[.cmod] (exec_size) reg reg Pseudocode: Evaluate(WrEn); srcregfile = regfile(src0); srcreg = reg(address[0]); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { srcsubreg = subreg(address[n] + addr_imm); dst.chan[n] = srcregfile.srcreg.srcsubreg; } } Description: The movi instruction performs a fast component-wise indexed move for subfields from src0 to dst. The source operand must be an indirectly-addressed register. All channels of the source operand share the same register number, which is provided by the register field of the first address subregister, with a possible immediate address offset. The register fields of the subsequent address subregisters are ignored by hardware. The subregister number of a source channel is provided by the subregister field of the corresponding address subregister. The destination register may be either a directly-addressed or an indirectly-addressed register. This instruction effectively performs a subfield shuffling from one register to another. Up to eight subfields can be selected by an instruction. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 196 Restrictions: Source operand cannot be accumulators. The source operand must be a general register. The source and destination must have the same type. The execution size must be <= 8 (1, 2, 4, or 8). The address register for the source must be aligned to the base (a0.0). The destination register (directly or indirectly addressed) must be 16-byte aligned. The destination stride in bytes must equal the source element size in bytes. The Align16 access mode is not allowed. All the index registers (address subregisters) used must point to the same GRF register. The instruction must use 1x1 indirect regioning. movi is always based on register offset zero no matter what the destination offset is. The destination offset is used in HW only to create channel enables. The first index register (a0.0) is always used to select the first element of the destination start from offset zero. Each index register is used to select 1 element if type is byte, 2 elements if type is Word, or 4 elements if type is DWord. Conditional Modifier is not allowed for this instruction. HW Implementation Details: The destination offset of the movi instruction is only used in HW to generate destination write enables. Each element of the destination is directly mapped to the index registers for the movi instruction. For byte movi, byte0 of the destination is selected by (a0.0[4:0]), byte1 is selected by (a0.1[4:0]), ..., and byte7 is selected by (a0.7[4:0]). The rest of the bytes are undefined. For word movi, byte0 of the destination is selected by (a0.0[4:1] & 0), byte1 is selected by (a0.0[4:1] & 1), byte2 is selected by (a0.1[4:1] & 0), byte3 is selected by (a0.1[4:1] & 1), ..., and byte15 is selected by (a0.7[4:1] & 1). The rest of the bytes are undefined. For DWord or float movi, byte0 of the destination is selected by (a0.0[4:2] & 00b), byte1 is selected by (a0.0[4:2] & 01b), byte2 is selected by (a0.0[4:2] & 10b), byte3 is selected by (a0.0[4:2] & 11b), byte4 is selected by (a0.1[4:2] & 00b), byte5 is selected by (a0.1[4:2] & 01b), ..., byte31 is selected by (a0.7[4:2] & 11b). For all 3 conditions above, a0.n[4:0] = a0.n[4:0] + addr_imm[4:0]. 6.43 mul – Multiply Opcode Instruction Description 65 (0x41) mul dst src0 src1 Multiply src0 and src1 storing the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type W W W D W, D D Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 197 Src Types Dst Type F F DF DF Format: [(pred)] mul[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] mul[.cmod] (exec_size) reg reg reg [(pred)] mul[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] * src1.chan[n]; } } Description: The mul instruction performs component-wise multiplication of src0 and src1 and stores the results in dst. ]: When both src0 and src1 are of type D or UD, only the low 16 bits of each element of src1 are used. The accumulator maintains full 48-bit precision. The macro described in the mach instruction should be used to obtain the full precision 64-bit multiplication result. Multiplication of two floating-point numbers follows the rules in mul – Multiply or mul – Multiply) based on the applicable floating-point mode. Floating-Point Multiplication of A (Column) and B (Row) in IEEE Mode –inf –finite -1.0 –denorm –0 +0 +denorm +1.0 +finite +inf NaN –inf +inf +inf +inf NaN NaN NaN NaN –inf –inf –inf NaN –finite +inf * –A +0 +0 –0 –0 A ** –inf NaN –1.0 +inf –B +1.0 +0 +0 –0 –0 –1.0 –B –inf NaN –denorm NaN +0 +0 +0 +0 –0 –0 –0 –0 NaN NaN –0 NaN +0 +0 +0 +0 –0 –0 –0 –0 NaN NaN +0 NaN –0 –0 –0 –0 +0 +0 +0 +0 NaN NaN +denorm NaN –0 –0 –0 –0 +0 +0 +0 +0 NaN NaN +1.0 –inf B –1.0 –0 –0 +0 +0 +1.0 B +inf NaN +finite –inf ** –A –0 –0 +0 +0 A * +inf NaN +inf –inf –inf –inf NaN NaN NaN NaN +inf +inf +inf NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN Note: * Result may be {+finite, +inf (overflow)}. ** Result may be {–inf (overflow), –finite}. Floating-Point Multiplication of A (Column) and B (Row) in ALT Mode –fmax –finite –1.0 –denorm –0 +0 +denorm +1.0 +finite +fmax *** –fmax +fmax +fmax +fmax –0 –0 +0 +0 –fmax –fmax –fmax –finite +fmax * –A +0 +0 –0 –0 A ** –fmax –1.0 +fmax –B +1.0 +0 +0 –0 –0 –1.0 –B –fmax –denorm +0 +0 +0 +0 +0 –0 –0 –0 –0 –0 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 198 –0 +0 +0 +0 +0 +0 –0 –0 –0 –0 –0 +0 –0 –0 –0 –0 –0 +0 +0 +0 +0 +0 +denorm –0 –0 –0 –0 –0 +0 +0 +0 +0 +0 +1.0 –fmax B –1.0 –0 –0 +0 +0 +1.0 B +fmax +finite –fmax ** –A –0 –0 +0 +0 A * +fmax +fmax –fmax –fmax –fmax –0 –0 +0 +0 +fmax +fmax +fmax *** Note: * Result may be {+finite, +fmax (overflow)}. ** Result may be {–fmax (overflow), –finite}. *** Result is undefined if A or B is {–inf, +inf, NaN}. Restrictions: Source operands cannot be accumulators. When operating on integers with at least one of the source being a DWord type (signed or unsigned), the destination cannot be floating-point (implementation note: the data converter only looks at the low 34 bits of the result). When operating on integers with at least one source having a DWord type (signed or unsigned), the Overflow and Sign flags are undefined. Therefore, conditional modifiers and saturation (.sat) cannot be used in this case. ]: When multiplying a DW and a W, the W has to be on src1, and the DW has to be on src0. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 199 6.44 nop – No Operation Opcode Instruction Description 126 (0x7E) nop Issue a dummy instruction and perform no operation. Pred Sat Cond Mod Src Mod N N N N Format: nop Syntax: nop Pseudocode: { ; // The null statement, which does nothing. } Description: Do nothing. The nop instruction takes an instruction dispatch but performs no operation. It can be used for assembly patching in memory, or to insert a delay in the program sequence. Restrictions: The nop instruction takes no instruction options other than Breakpoint. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 200 6.45 not – Logic Not Opcode Instruction Description 4 (0x04) not dst src0 Bitwise NOT of src0 storing the result in dst. Pred Sat Cond Mod Src Mod Y N Y Y Generation Src Type Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] not[.cmod] (exec_size) dst src0 Syntax: [(pred)] not[.cmod] (exec_size) reg reg [(pred)] not[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = ~ src0.chan[n]; } } Description: The not instruction performs logical NOT operation (or one's complement) of src0 and storing the results in dst. A register source operand can use a source modifier:  Any source modifier is numeric, optionally changing a source value s to -s, abs(s), or -abs(s) before the NOT operation. This operation does not produce sign or overflow conditions. Only the .e/.z or .ne/.nz conditional modifiers should be used. Restrictions: Source modifier is not allowed if source is an accumulator. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 201 6.46 or – Logic Or Opcode Instruction Description 6 (0x06) or dst src0 src1 Bitwise OR of src0 and src1 storing the result in dst. Pred Sat Cond Mod Src Mod Y N Y Y Generation Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] or[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] or[.cmod] (exec_size) reg reg reg [(pred)] or[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] | src1.chan[n]; } } Description: The or instruction performs component-wise logic OR operation between src0 and src1 and stores the results in dst. Register source operands can use source modifiers:  Any source modifier is numeric, optionally changing a source value s to -s, abs(s), or -abs(s) before the OR operation. This operation does not produce sign or overflow conditions. Only the .e/.z or .ne/.nz conditional modifiers should be used. Restrictions: Source modifier is not allowed if source is an accumulator. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 202 6.47 pln – Plane Opcode Instruction Description 90 (0x5A) pln dst src0 src1 Compute a plane equation (w = p*u + q*v + r) of scalar (p, q, r) from src0 and vector src1 (and implied vector src2). Store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Src Types Dst Type F F Format: [(pred)] pln[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] pln[.cmod] (exec_size) reg reg reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { float dwP = src0.RegNum.SubRegNum[bits4:2]; // A DWord-aligned scalar. float dwQ = src0.RegNum.(SubRegNum[bit4:2] | 0x1); // Second component. float dwR = src0.RegNum.(SubRegNum[bit4:2] | 0x3); // Fourth component. if ( ExecSize == 8 ) src2 = src1.(RegNum + 1) // Next GRF register. else // ExecSize == 16 src2 = src1.(RegNum + 2) // The two GRF registers after RegNum and RegNum + 1. if ( WrEn.chan[n] ) { dst.chan[n] = dwP * src1.chan[n] + dwQ * src2.chan[n] + dwR; } } Description: The pln instruction computes a component-wise plane equation (w = p*u+q*v+r where u/v/w are vectors and p/q/r are scalars) of src0 and src1 and stores the results in dst. src1 is the input vector u. If ExecSize is 8 then the second input vector v is implied from src1 as the next adjacent GRF register. If ExecSize is 16 then the second input vector v is implied from src1 as the two GRF registers after the two registers used by input vector u. src0 provides input scalars p, q, and r, where p is the scalar value based on the region description of src0 and q and r are the scalar values implied from the src0 region. Specifically, q is the second component and r is the fourth component of the 4-tuple (128-bit aligned) that p belongs to. Restrictions: This is a specialized instruction that only supports an execution size (ExecSize) of 8 or 16. The src0 region must be a replicated scalar (with HorzStride == VertStride == 0). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 203 src0 must specify .0 or .4 as the subregister number, corresponding to a subregister byte offset of 0 or 16. Source operands cannot be accumulators. 6.48 ret – Return Opcode Instruction Description 45 (0x2d) ret null src0 Return from a subroutine. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type D, UD Format: [(pred)] ret (exec_size) null src0 Syntax: [(pred)] ret (exec_size) null reg Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { PcIP[n] = src0.chan[0]; CallMask[n] = 0; } else { PcIP[n] = IP + 1; } } for ( n = exec_size; n < 32; n++ ) { PcIP[n] = IP + 1; } if ( CallMask[n:0] == 0) ) { // all channels are zero Jump(src0.chan[0]); CallMask = src0.chan[1]; } Description: Return execution to the code sequence that called a subroutine. The ret instruction can be predicated or non-predicated. If non-predicated, all channels jump to the return IP in the first channel of src0 and restore CallMask from the second channel of src0. If predicated, the enabled channels jump to the return IP from the first channel of src0 and the corresponding bits in the CallMask are cleared to zero; if all CallMask bits are zero after the ret instruction, then execution jumps to the return IP from the first channel of src0. When SPF is on, the predication control must be scalar. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 204 Restrictions: This instruction cannot take accumulator as source. The src0 regioning control must be <2;2,1>, 6.49 rndd – Round Down Opcode Instruction Description 69 (0x45) rndd dst src0 Round floating-point src0 down to an integral floating-point value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F F Format: [(pred)] rndd[.cmod] (exec_size) dst src0 Syntax: [(pred)] rndd[.cmod] (exec_size) reg reg [(pred)] rndd[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = floor(src0.chan[n]); } } Description: The rndd instruction takes component-wise floating point downward rounding (to the integral float number closer to negative infinity) of src0 and storing the rounded integral float results in dst. This is commonly referred to as the floor() function. Each result follows the rules in the following tables based on the floating-point mode. Floating-Point Round Down in IEEE mode src0 –inf –finite –denorm –0 +0 +denorm +finite +inf NaN dst –inf -finite ^ –0 +0 +0 ** +inf NaN Notes: ^ -0 as denorms are flushed to zero. ** Result may be {+finite, +0}. Floating-Point Round Down in ALT mode src0 –fmax –finite –denorm –0 +0 +denorm +finite +fmax *** dst –fmax -finite –0 –0 +0 +0 ** +fmax Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 205 src0 –fmax –finite –denorm –0 +0 +denorm +finite +fmax *** dst –fmax -finite –0 –0 +0 +0 ** +fmax Notes: ** Result may be {+finite, +0}. *** Result is undefined if src0 is {–inf, +inf, NaN}. Restrictions: No accumulator access, implicit or explicit. 6.50 rnde – Round to Nearest or Even Opcode Instruction Description 70 (0x46) rnde dst src0 Round floating-point src0 to the nearest or even integral floating-point value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F F Format: [(pred)] rnde[.cmod] (exec_size) dst src0 Syntax: [(pred)] rnde[.cmod] (exec_size) reg reg [(pred)] rnde[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { if ( src0.chan[n] - floor(src0.chan[n]) > 0.5f ) { dst.chan[n] = floor(src0.chan[n]) + 1; } else if ( src0.chan[n] - floor(src0.chan[n]) < 0.5f ) { dst.chan[n] = floor(src0.chan[n]); } else { if ( floor(src0.chan[n]) is odd ) { dst.chan[n] = floor(src0.chan[n]) + 1; } else { dst.chan[n] = floor(src0.chan[n]); } } } } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 206 Description: The rnde instruction takes component-wise floating point round-to-even operation of src0 with results in two pieces – a downward rounded integral float results stored in dst and the round-to-even increments stored in the rounding increment bits. The round-to-even increment must be added to the results in dst to create the final round-to-even values to emulate the round-to-even operation, commonly known as the round() function. The final results are the one of the two integral float values that is nearer to the input values. If the neither possibility is nearer, the even alternative is chosen. Each result follows the rules in the following tables based on the floating-point mode. Floating-Point Round to Nearest or Even in IEEE mode src0 –inf –finite –denorm –0 +0 +denorm +finite +inf NaN dst –inf * –0 –0 +0 +0 ** +inf NaN Notes: * Result may be {–finite, –0}. ** Result may be {+finite, +0}. Floating-Point Round to Nearest or Even in ALT mode src0 –fmax –finite –denorm –0 +0 +denorm +finite +fmax *** dst –fmax * –0 –0 +0 +0 ** +fmax Notes: * Result may be {–finite, –0}. ** Result may be {+finite, +0}. *** Result is undefined if src0 is {–inf, +inf, NaN}. Restrictions: No accumulator access, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 207 6.51 rndu – Round Up Opcode Instruction Description 68 (0x44) rndu dst src0 Round floating-point src0 up to an integral floating-point value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F F Format: [(pred)] rndu[.cmod] (exec_size) dst src0 Syntax: [(pred)] rndu[.cmod] (exec_size) reg reg [(pred)] rndu[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { if ( src0.chan[n] - floor(src0.chan[n]) > 0.0f ) { dst.chan[n] = floor(src0.chan[n]) + 1; } else { dst.chan[n] = src0.chan[n]; } } } Description: The rndu instruction takes component-wise floating point upward rounding (to the integral float number closer to positive infinity) of src0, commonly known as the ceiling() function. Each result follows the rules in the following tables based on the floating-point mode. Floating-Point Round Up in IEEE mode src0 –inf –finite –denorm –0 +0 +denorm +finite +inf NaN dst –inf * –0 –0 +0 ^ +finite +inf NaN Notes: * Result may be {–finite, –0}. ^ +0 as denorms are flushed to zero. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 208 Floating-Point Round Up in ALT mode src0 –fmax –finite –denorm –0 +0 +denorm +finite +fmax *** dst –fmax * –0 –0 +0 +0 +finite +fmax Notes: * Result may be {–finite, –0}. *** Result is undefined if src0 is {–inf, +inf, NaN}. Restrictions: No accumulator access, implicit or explicit. 6.52 rndz – Round to Zero Opcode Instruction Description 71 (0x47) rndz dst src0 Round floating-point src0 toward zero to an integral floating-point value and store in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Type Dst Type F F Format: [(pred)] rndz[.cmod] (exec_size) dst src0 Syntax: [(pred)] rndz[.cmod] (exec_size) reg reg [(pred)] rndz[.cmod] (exec_size) reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = floor(src0.chan[n]); if ( abs(src0.chan[n]) < abs(dst.chan[n]) ) { dst.chan[n] = floor(src0.chan[n]) + 1; } else { dst.chan[n] = floor(src0.chan[n]); } } } Description: The rndz instruction takes component-wise floating point round-to-zero operation of src0 with results in two pieces – a downward rounded integral float results stored in dst and the round-to-zero increments stored in the rounding increment bits. The round-to-zero increment must be added to the results in dst to Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 209 create the final round-to-zero values to emulate the round-to-zero operation, commonly known as the truncate() function. The final results are the one of the two closest integral float values to the input values that is nearer to zero. Floating-Point Round to Zero in IEEE mode src0 –inf –finite –denorm –0 +0 +denorm +finite +inf NaN dst –inf * –0 –0 +0 +0 ** +inf NaN Notes: * Result may be {–finite, –0}. ** Result may be {+finite, +0}. Floating-Point Round to Zero in ALT mode src0 –fmax –finite –denorm –0 +0 +denorm +finite +fmax *** dst –fmax * –0 –0 +0 +0 ** +fmax Notes: * Result may be {–finite, –0}. ** Result may be {+finite, +0}. *** Result is undefined if src0 is {–inf, +inf, NaN}. Restrictions: No accumulator access, implicit or explicit. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 210 6.53 sad2 – Sum of Absolute Difference 2 Opcode Instruction Description 80 (0x50) sad2 dst src0 src1 Perform a two-wide sum-of-absolute-difference operation on a 2-tuple basis of src0 and src1, and store the scalar result to the first channel per 2-tuple in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type B, UB W, UW Format: [(pred)] sad2[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] sad2[.cmod] (exec_size) reg reg reg [(pred)] sad2[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 2 ) { if ( WrEn.chan[n] ) { dst.chan[n] = abs(src0.chan[n] - src1.chan[n]) + abs(src0.chan[n+1] - src1.chan[n+1]); } } Description: The sad2 instruction takes source data channels from src0 and src1 in groups of 2-tuples. For each 2- tuple, it computes the sum-of-absolute-difference (SAD) between src0 and src1 and stores the scalar result in the first channel of the 2-tuple in dst. The results are also stored in the accumulator register. The destination operand and the accumulator maintain 16 bits per channel precision. The destination register must be aligned to even word (DWord). The even words in the destination region will contain the correct data. The odd words are also written but with undefined values. Restrictions: Source operands cannot be accumulators. The execution size cannot be 1 as the computation requires at least two data channels. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 211 6.54 sada2 – Sum of Absolute Difference Accumulate 2 Opcode Instruction Description 81 (0x51) sada2 dst src0 src1 Perform a two-wide sum-of-absolute-difference operation on a 2-tuple basis of src0 and src1, added to that from the accumulator, and store the scalar result to the first channel per 2-tuple in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type B, UB W, UW Format: [(pred)] sada2[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] sada2[.cmod] (exec_size) reg reg reg [(pred)] sada2[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n += 2 ) { uwTmp = abs(src0.chan[n] - src1.chan[n]) + abs(src0.chan[n+1] - src1.chan[n+1]); if ( WrEn.chan[n] ) { dst.chan[n] = uwTmp + acc[n]; } } Description: The sada2 instruction takes source data channels from src0 and src1 in groups of 2-tuples. For each 2- tuple, it computes the sum-of-absolute-difference (SAD) between src0 and src1, adds the intermediate result with the accumulator value corresponding to the first channel, and stores the scalar result in the first channel of the 2-tuple in dst. The destination operand and the accumulator maintain 16 bits per channel precision. Higher precision (guide bits) stored in the accumulator allows up to 64 rounds of sada2 instructions to be issued back to back without overflowing the accumulator. The destination register must be aligned to even word (DWord). The even words in the destination region will contain the correct data. The odd words are also written but with undefined values. Restrictions: Source operands cannot be accumulators. The execution size cannot be 1 as the computation requires at least two data channels. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 212 6.55 sel – Select Opcode Instruction Description 2 (0x02) (pred) sel dst src0 src1 Copy either src0 or src1 to dst based on predication or conditional modifier. Pred Sat Cond Mod Src Mod Y Y Y Y Src Types Dst Type *B, *W, *D *B, *W, *D F F DF DF Format: (pred) sel[.cmod] (exec_size) dst src0 src1 Syntax: (pred) sel[.cmod] (exec_size) reg reg reg (pred) sel[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn, NoPMask); if (cmod == “0000”) { // no CMod Evaluate(PMask); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { if ( PMask.channel[n] ) { dst.chan[n] = src0.chan[n]; } else { dst.chan[n] = src1.chan[n]; } } } } else { // with CMod Evaluate(CMod); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { if ( CMod.chan[n] ) { dst.chan[n] = src0.chan[n]; } else { dst.chan[n] = src1.chan[n]; } } } } Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 213 Description: The sel instruction selectively moves the components in src0 or src1 into the channels of dst based on the predication. On a channel by channel basis, if the channel condition is true, data in src0 is moved into dst. Otherwise, data in src1 is moved into dst. As the predication is used to select the two sources, it is not included in the evaluation of WrEn. The predicate clause is mandatory if cmod is omitted/0000b. If both predication and the conditional modifier are omitted, the results are undefined. If the conditional modifier is specified (not 0000b, a compare is performed and the resulting condition flag is used for the sel instruction. Conditional modifiers .ge and .l follow the cmpn rules, and all other conditional modifiers follow the cmp rules. Predication is not allowed in this mode. A sel instruction with cmod .l is used to emulate a MIN instruction. A sel instruction with cmod .ge is used to emulate a MAX instruction. For a sel instruction with a .l or .ge conditional modifier, if one source is NaN and the other not NaN, the non-NaN source is the result. If both sources are NaNs, the result is NaN. For all other conditional modifiers, if either source is NaN then src1 is selected. A sel instruction without a conditional modifier always copies a denorm source value to a denorm destination value (in the manner of a raw move). A sel instruction with a conditional modifier flushes any selected denorm source value to a zero destination value. Format conversion is not allowed. The sel instruction uses any conditional modifier internally and does not update the flag register if a conditional modifier is used. Restrictions: ]: The maximum execution size is 16. 6.56 send Message Opcode Instruction Description 49 (0x31) send Send a message stored in GRF starting at to a shared function identified by along with control from with a GRF writeback location at . Pred Sat Cond Mod Src Mod Src Types Dst Type Y [FLT] [INT] Format: [(pred)] send (exec_size) Syntax: [(pred)] send (exec_size) reg greg imm6 reg32a [(pred)] send (exec_size) reg greg imm6 imm32 Pseudocode: Evaluate(WrEn); = WrEn; Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 214 = .RegNum; MessageEnqueue(, , , , ); Description: The send instruction performs data communication between a thread and external function units, including shared functions (Sampler, Data Port Read, Data Port Write, URB, and Message Gateway) and some fixed functions (e.g. Thread Spawner, who also have an unique Shared Function ID). The send instruction adds an entry to the EU’s message request queue. The request message is stored in a block of contiguous GRF registers. The response message, if present, will be returned to a block of contiguous GRF registers. The return GRF writes may be in any order depending on the external function units. is the lead GRF register for request. is the lead GRF register for response. The message descriptor field contains the Message Length (the number of consecutive GRF registers) and the Response Length (the number of consecutive GRF registers). It also contains the header present bit, and the function control signals. The extend mesage descriptor field contains the target function ID. WrEn is forwarded to the target function in the message sideband. The send instruction is the only way to terminate a thread. When the EOT (End of Thread) bit of is set, it indicates the end of thread to the EU, the Thread Dispatcher and, in most cases, the parent fixed function. Message descriptor field can be a 32-bit immediate, imm32, or a 32-bit scalar register, . GEN restricts that the 32-bit scalar register must be the leading dword of the address register. It should be in the form of a0.0<0;1,0>:ud. When is a register operand, only the lower 29 bits of are used. is a 6-bit immediate, imm6. The lower 4bits of the specifies the SFID for the message. The MSb of the message descriptor, the EOT field, always comes from bit 127 of the instruction word, which is the MSb of imm6. A thread must terminate with a send instruction with EOT turned on. is a 256-bit aligned GRF register. It serves as the leading GRF register of the request. serves for two purposes: to provide the leading GRF register location for the response message if present, and to provide parameters to form the channel enable sideband signals. signals whether there is a response to the message request. It can be either a null register, a direct-addressed GRF register or a register-indirect GRF register. Otherwise, hardware behavior is undefined. If is null, there is no response to the request. Meanwhile, the Response Length field in must be 0. Certain types of message requests, such as memory write (store) through the Data Port, do not want response data from the function unit. If so, the posted destination operand can be null. If is a GRF register, the register number is forwarded to the shared function. In this case, the target function unit must send one or more response message phases back to the requesting thread. The number of response message phases must match the Response Length field in , which of course cannot be zero. For some cases, it could be an empty return message. An empty return message is defined as a single phase message with all channel enables turned off. The subregister number, horizontal stride, destination mask and type fields of are always valid and are used in part to generate the WrEn. This is true even if is a null register (this is an exception for null as for most cases these fields are ignored by hardware). The 16-bit channel enables of the message sideband are formed based the WrEn. Interpretation of the channel enable sideband signals is subject to the target external function. In general for a ‘send’ instruction with return messages, they are used as the destination dword write mask for the GRF registers Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 215 starting at . For a message that has multiple return phases, the same set of channel enable signals applies to all the return phases. Thread managed memory coherency: A special usage of using non-null is to support write-commit signaling for memory write service by the Data Port Write unit. If is not null for a memory write request, the Data Port along with the Data Cache or Render Cache will wait until all the posted writes for the request have reached the coherent domain before sending back to the requesting thread an empty message to register. A memory write reaching the coherent domain, also referred to as reaching the global observable state, means that subsequent read to the same memory location, no matter which thread issues the read, must return the data of the write. The destination dependency control, {NoDDClr}, can be used in this instruction. This allows software to control the destination dependencies for multiple ‘read’-type messages similar to that for multiple instructions using EU execution pipeline. As send does not check register dependencies for the post destination, {NoDDChk} should not be used for this instruction. Message Descriptor Definition Bit Description 31 Reserved : MBZ 30 Reserved : MBZ 29 Reserved : MBZ 28:25 Message Length. This field specifies the number of 256-bit GRF registers starting from to be sent out on the request message payload. Valid value ranges from 1 to 15. A value of 0 is considered erroneous. Format = U4 Range = [1,15] 24:20 Response Length. This field indicates the number of 256-bit registers expected in the message response. The valid value ranges from 0 to 16. A value 0 indicates that the request message does not expect any response. The largest response supported is 16 GRF registers. Format = U5 Range = [0,16] 19 Header Present. If set, indicates that the message includes a header. Depending on the target shared function, this field may be restricted to either enabled or disabled. Refer to the specific shared function section for details. Format = Enable 18:0 Function Control This field is intended to control the target function unit. Refer to the section on the specific target function unit for details on the contents of this field. Extended Message Descriptor Definition Bit Description 5 End Of Thread This field, if set, indicates that this is the final message of the thread and the thread’s resources can be reclaimed. 4 reserved Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 216 Bit Description 3:0 Target Function ID This field indicates the function unit for which the message is intended. Refer to “GPU Overview” document for the mapping of Shared Function IDs Sideband Signals Associated with Each Message Sent to the Shared Function provides a summary of the signals associated with each message that is sent to the shared function. It contains fields from the send instruction as well as fields from control register cr0 and state register sr0. Sideband Signals Associated with Each Message Sent to the Shared Function Signal Bits Source EOT 1 End of Thread: Sourced from the EOT bit in send instruction word SFID 3 Shared Function Identifier: Sourced from the target function ID field in of send MLEN 4 Message Length: Sourced from the message length field in of send RLEN 5 Response Length: Sourced from the response length field in of send FC 19 Function Control: Sourced from the function control field in of send REG 7 Destination Register: Sourced from the 256-bit register aligned register number of the field of send CE 16 Channel Enable: Sourced from the write enable of send CLEAR 1 Destination Register Clear: Source from the Destination Dependency Control field (inverse of NoDDClr) in send instruction word FFID 4 Fixed Function Identifier: Sourced from the Fixed Function ID field in sr0 EUID 4 Execution Unit Identifier: Sourced from the EUID field in sr0 TID 2 Thread Identifier: Sourced from the TID field in sr0 Restrictions: Software must obey the following rules in signaling the end of thread using the send instruction:  The posted destination operand must be null. o No acknowledgement is allowed for the send instruction that signifies the end of thread. This is to avoid deadlock as the EU is expecting to free up the terminated thread’s resource.  A thread must terminate with a send instruction with message to a shared function on the output message bus; therefore, it cannot terminate with a send instruction with message to the following shared functions: Sampler unit, NULL function o For example, a thread may terminate with a URB write message or a render cache write message. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 217  A root thread originated from the media (generic) pipeline must terminate with a send instruction with message to the Thread Spawner unit. A child thread should also terminate with a send to TS. Please refer to the Media Chapter for more detailed description. The send instruction can not update accumulator registers. Saturate is not supported for send instruction. ThreadCtrl are not supported for send instruction. The send with EOT should use register space R112-R127 for . This is to enable loading of a new thread into the same slot while the message with EOT for current thread is pending dispatch. 6.57 sendc – Conditional Send Message Opcode Instruction Description 50 (0x32) sendc dst src desc exdesc Wait for dependencies in the TDR Register to clear, then send a message stored in registers starting at src to a shared function identified by exdesc along with control from desc with a general register writeback location at dst. Pred Sat Cond Mod Src Mod Y N N N Src Type Dst Type [FLT], [INT] Format: [(pred)] sendc (exec_size) dst src0 exdesc desc Syntax: [(pred)] sendc (exec_size) reg reg reg32a imm4 [(pred)] sendc (exec_size) reg reg imm32 imm4 Pseudocode: if ( TDR[7] ... || TDR[2] || TDR[1] || TDR[0] ) { wait; } Evaluate(WrEn); MsgChEnable = WrEn; SourceReg = src0.RegNum; MessageEnqueue(MsgChEnable, ResponseReg, SourceReg, desc, exdesc); Description: The sendc instruction has the same behavior as the send instruction except the following. sendc first checks the dependent threads inside the Thread Dependency Register. There are up to 8 dependent threads in the TDR register. The sendc instruction executes only when all the dependent threads in the TDR register are retired. Restrictions: The sendc instruction has the same restrictions as the send instruction. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 218 6.58 shl – Shift Left Opcode Instruction Description 9 (0x09) shl dst src0 src1 Shift the bits in src0 left by the number of bits indicated in src1. Store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Generation Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] shl[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] shl[.cmod] (exec_size) reg reg reg [(pred)] shl[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { shiftCnt = src1.chan[n] & 0x1F; // Always use low 5 bits for shift count. dst.chan[n] = src0.chan[n] << shiftCnt; } } Description: Perform component-wise logical left shift of the bits in src0 by the shift count indicated in src1, storing the results in dst, inserting zero bits in the number of LSBs indicated by the shift count. The shift count is taken from the low five bits of src1, regardless of the src1 type and treated as an unsigned integer in the range 0 to 31. Hardware detects overflow properly and uses it to perform any saturation operation on the result, as long as the shifted result is within 33 bits. Otherwise, the result is undefined. Note: For word and DWord operands, the accumulators have 33 bits. Restrictions: Accumulator cannot be destination, implicit or explicit. Results of saturation in packed-DWord mode are unpredicable. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 219 6.59 shr – Shift Right Opcode Instruction Description 8 (0x08) shr dst src0 src1 Shift the bits in src0 right by the number of bits indicated in src1. Store the result in dst. Pred Sat Cond Mod Src Mod Y Y Y Y Generation Src Types Dst Type UB, UW, UD UB, UW, UD Format: [(pred)] shr[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] shr[.cmod] (exec_size) reg reg reg [(pred)] shr[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { shiftCnt = src1.chan[n] & 0x1F; // Always use low 5 bits for shift count. dst.chan[n] = src0.chan[n] >> shiftCnt; } } Description: Perform component-wise logical right shift with zero insertion of the bits in src0 by the shift count indicated in src1, storing the results in dst. Insert zero bits in the number of MSBs indicated by the shift count. The shift count is taken from the low five bits of src1, regardless of the src1 type and treated as an unsigned integer in the range 0 to 31. src0 and dst can have different types and can be signed or unsigned. Note: For word and DWord operands, the accumulators have 33 bits. Note: For unsigned src0 types, shr and asr produce the same result. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 220 6.60 subb – Integer Subtraction with Borrow Opcode Instruction Description 79 (0x4F) subb dst src0 src1 Subtract unsigned integer src1 from src0. Store the result in dst and store the borrow (0 or 1) as a 32-bit value in acc. Pred Sat Cond Mod Src Mod Y N Y N Src Types Dst Type UD UD Format: [(pred)] subb[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] subb[.cmod] (exec_size) reg reg reg [(pred)] subb[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] - src1.chan[n]; acc.chan[n] = borrow(src.chan[n] - src1.chan[n]); } } Description: The subb instruction performs component-wise subtraction of src0 and src1 and stores the results in dst, it also stores the borrow into acc. If the operation produces a borrow (src0 < src1), write 0x00000001 to acc, else write 0x00000000 to acc. . Restrictions: AccWrEn is required. The accumulator is an implicit destination and thus cannot be an explicit destination operand. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 221 6.61 wait – Wait Notification Opcode Instruction Description 48 (0x30) wait nreg Wait for notification on the notification register nreg. Pred Sat Cond Mod Src Mod N N N N Src Type Dst Type UD UD Format: wait (exec_size) nreg Syntax: wait (1) n# Pseudocode: N/A Description: The wait instruction evaluates the value of the notification count register nreg. If nreg is zero, thread execution is suspended and the thread is put in ‘wait_for_notification’ state. If nreg is not zero (i.e., one or more notifications have been received), nreg is decremented by one and the thread continues executing on the next instruction. If a thread is in the ‘wait_for_notification’ state, when a notification arrives, the notification count register is incremented by one. As the notification count register becomes nonzero, the thread wakes up to continue execution and at the same time the notification register is decremented by one. If only one notification arrived, the notification register value becomes zero. However, during the above mentioned time period, it is possible that more notifications may arrive, making the notification register nonzero again. When multiple notifications are received, software must use wait instructions to decrement notification count registers for each notification. Notification register n0:ud is for thread to thread communication (via the Message Gateway shared function) and n1:ud for host to thread communication (through MMIO registers). See the Message Gateway chapter for thread-thread communication . Restrictions: src0 and dst must be n0, n1, or n2. Execution size must be 1 as the notification registers are scalar. Predication is not allowed. Two back-to-back wait instructions are not allowed. At minimum, a nop instruction must be inserted between two wait instructions. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 222 6.62 while – While Opcode Instruction Description 39 (0x27) while JIP Mark the end of a do-while block of code. Pred Sat Cond Mod Src Mod Y N N N Format: [(pred)] while (exec_size) JIP Syntax: ]: [(pred)] while (exec_size) imm16 Pseudocode: Evaluate(WrEn); for ( n = 0; n < 32; n++ ) { if (WrEn.chan[n] ) { PcIP[n] = IP + JIP; } else { PcIP[n] = IP + 1; } } if (cmod == 0) { if ( | PMask == 1 ) { // any enabled channel true Jump(IP + JIP); } } Description: The while instruction marks the end of a do-while block. The instruction first evaluates the loop termination condition for each channel based on the current channel enables and the predication flags specified in the instruction. If any channel has not terminated, a branch is taken to a destination address specified in the instruction, and the loop continues for those channels. Otherwise, execution continues to the next instruction. ]: The following table describes the 16-bit jump target offset JIP. JIP is a signed 16-bit number, added to IP pre-increment, and should point to the first instruction with the do label of the do-while block of code. It should be a negative number for the backward referencing. In GEN binary, JIP is at location src1 and must be of type W (signed word integer). JIP Bits Description 31:16 Reserved: MBZ. 15:0 JIP (Jump Target Offset). Specifies the jump distance in 64-bit units if a jump is taken for the instruction. Format = S15. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 223 If SPF is ON, none of the PcIP are updated. Restrictions: The execution size must be the same for the while instruction and any break and cont instructions of the same code block. 6.63 xor – Logic Xor Opcode Instruction Description 7 (0x07) xor dst src0 src1 Bitwise XOR of src0 and src1 storing the result in dst. Pred Sat Cond Mod Src Mod Y N Y Y Generation Src Types Dst Type *B, *W, *D *B, *W, *D Format: [(pred)] xor[.cmod] (exec_size) dst src0 src1 Syntax: [(pred)] xor[.cmod] (exec_size) reg reg reg [(pred)] xor[.cmod] (exec_size) reg reg imm32 Pseudocode: Evaluate(WrEn); for ( n = 0; n < exec_size; n++ ) { if ( WrEn.chan[n] ) { dst.chan[n] = src0.chan[n] ^ src1.chan[n]; } } Description: The xor instruction performs component-wise logic XOR operation between src0 and src1 and stores the results in dst. Register source operands can use source modifiers:  Any source modifier is numeric, optionally changing a source value s to -s, abs(s), or -abs(s) before the XOR operation. This operation does not produce sign or overflow conditions. Only the .e/.z or .ne/.nz conditional modifiers should be used. Restrictions: Source modifier is not allowed if source is an accumulator. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 224 7. EU Programming Guide 7.1 Assembler Pragmas 7.2 Declarations A register or a register region can be declared as a symbol using the following form .declare Base=RegFile RegBase {.SubRegBase} ElementSize=ElementSize {SrcRegion=DefaultSrcRegion} {DstRegion=DefaultDstRegion} {Type=DefaultType} The register file, the base of the register origin and the element size (in unit of bytes) are the mandatory parameters for a declared register region. Optionally, the base of the sub-register address, the default source region, the default destination region and the default type can be provided in the declaration for the symbol. For immediate register addressing mode, the declared symbol can be used in the following Cartesian form (RegOff, SubRegOff)<=RegNum = RegBase+ RegOff; SubRegNum = SubRegBase+ SubRegOff or in the following simplified row-aligned form (RegOff)<=RegNum = RegBase+ RegOff; SubRegNum = SubRegBase For register-indirect-register-addressing mode, the declared symbol can be used to provide immediate address term in the following Cartesian form [IdxReg, RegOff, SubRegOff]<= RegNum (byte-aligned) = [IdxReg]+(RegBase+ RegOff)*32 + (SubRegBase + SubRegOff)*ElementSize or in the following simplified row-aligned form [IdxReg, RegOff]<= RegNum (byte-aligned) = [IdxReg]+(RegBase+ RegOff)*32 or in the form without the immediate address term [IdxReg]<= RegNum (byte-aligned) = [IdxReg]+ RegBase 7.2.1 Defaults and Defines The default execution size is set according to the destination register type as the following Destination Register Type Default Execution Size UB | B (16) UW | W (16) F | UD | D (8) The default execution size can be overwritten globally for all instructions using .default_execution_size(Execution_Size) or be set according the destination register type using .default_execution_size_Type(Execution_Size) Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 225 The default register type can be set for all register files using .default_register_typeType or be set per register file using .default_register_type_RegFileType The default source register region for all symbols can be set using .default_source_register_region or be set per register type using .default_source_register_region_type The default destination register region for all symbols can be set using .default_destination_register_region< HorzStride> or be set per register type using .default_destination_register_region_type< HorzStride> Finally, the precompiler supports the string replacement statement of .define in the following form .defineExpression Notes:  .declare does not support nesting. In other words, each symbol in .declare must be self defined. This would allow the pre-processor to expand all symbols in one pass.  .define does support nesting. Only string substitution is supported (currently).  White space within square, angle and round brackets are allowed for easy source code alignment. 7.2.2 Example Pragma Usages Example: Declaration for 8x4=32-Byte Regions: The following symbol Block can be used to address any 8x4 byte region within the Cartisian system of a 16x8 byte GRF register area starting from r0. Declaration // 32x4 Byte Array.declare BlockBase=r0 ElementSize=1 Region=<32;8,1>Type=b Fully-Expressed Instr mov(32)?:br0.16<32;8,1>:b// r0 xxxxxxxxxxxxxxxxooooooooxxxxxxxx// r1 xxxxxxxxxxxxxxxxooooooooxxxxxxxx// r2 xxxxxxxxxxxxxxxxooooooooxxxxxxxx// r3 xxxxxxxxxxxxxxxxooooooooxxxxxxxx Short-handed Instr Mov?:bBlock(0,16)// (0,16): RegNum=0, SubRegNum=16 Example: Declaration for 8x1 Float Regions: The following symbol Trans can be used to address any 8x1 float region within the Cartisian system of a 8x4 float GRF register area starting from r5. Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 226 Declaration // 8x4 float Array starting at r5.declare Trans Base=r5 ElementSize=4 Region=<0;8,1> Type=f Fully-Expressed Instr mov(8)?:fr6.0<0;8,1>:f// 2nd 16x1 Row of Trans. Matrix // r5 FFFFFFFF// r6 OOOOOOOO// r7 FFFFFFFF// r8 FFFFFFFF Short-handed Instr mov?:fTrans(1) // RegNum = 5+1 = 6 Example: Declaration for 8x1 Float Regions with 1x1 Indirect Addressing: Trans region defined (same as in the previous example) is used in conjunction with the address register. Declaration //8x4 float data array and 16x1 word address array.declare TransBase=r5 ElementSize=4 Region=<0;8,1> Type=f Fully-Expressed Instr mov(8)?:fr[a0.0,224]<0;8,1>:f Short-handed Instr mov?:fTrans[a0.0,2] // [a0.0 + 5*32 + 2*32] Example: Declaration with VxH Indirect Addressing: The VxH register-indirect-register-addressing for Trans can be provided in the following short-hand form Declaration //8x4 float data array and word indices.declare TransBase=r5 ElementSize=4 Region=<0;8,1> Type=f Fully-Expressed Instr mov(8)?:fr[a0.0,224]<1,0>:f Short-handed Instr mov?:fTrans[a0.0,2]<1,0> // [a0.0+224] [a0.1+224] … [a0.7+224] Example: Declaration with Vx1 Indirect Addressing: As width (4) is smaller than the execution region size (8), multiple indexed registers are used. Declaration //8x4 float data array and word address array.declare TransBase=r5 ElementSize=4 Region=<0;8,1> Type=f Fully-Expressed Instr mov(8)?:fr[a0.0,244]<4,1>:f Short-handed Instr mov?:fTrans[a0.0,2]<4,1>// [a0.0+224] [a0.1+224] Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 227 7.2.3 Assembly Programming Guideline The following program skeleton illustrates the basic structure of a typical assembly program. // single line comment /* block comment*/ // macros, include, etc. Are global – handled by the pre-processor// applies to all code that follows in sequence // ------------ some kernel --------------------- ------.kernel // [REQUIRED]// ------- Register requirements ------ -- .reg_count_total // [REQUIRED] a more direct way to specify the exact parameters require .reg_count_payload // [REQUIRED] rather than to have to indirectly do that by adding the// the payload and temps together to get the total (as is the case now)// Note: no more “reg-count-temp” // -------------- Defaults ----- ---------- // these should be specified per-kernel and have only kernel- scope // Same defaults as those already defined in the ISA doc, but just // moved within the kernel to make each kernel completely self- sufficient// and not impacted defaults of earlier kernels // --------- Memory Requirements ---------// [optional] memory block info (just a placeholder for now...) // memory block descriptor a (TBD) // memory block descriptor b (TBD) // memory block descriptor c (TBD) // memory block descriptor d (TBD) // ---------------- Code ---------------- .code// [REQUIRED]// labels are code-block scope .end_code// [REQUIRED] .end_kernel// [REQUIRED] // -- ------- next kernel ------------- // --------- next kernel ------------- // ... 7.3 Usage Examples 7.3.1 Vector Immediate The immediate form of vector allows a constant vector to be in-lined in the instruction stream. An immediate vector is denoted by type v as imm32:v, where the 32-bit immediate field is partitioned into 8 4- bit subfields. Each 4-bit subfield contains a signed integer value. Therefore each 4-bit subfield has a range of [-8, +7]. This is depicted in the following figure. 31 28 27 24 23 20 19 16 15 12 11 8 7 4 3 0 V7 V6 V5 V4 V3 V2 V1 V0 7.3.1.1 Supporting DirectX 10 Pixel Shader Indexing When a DirectX 10 Pixel Shader program is converted to run on GEN in channel-serial mode at 16 pixels in parallel, the per-pixel index must be translated into 16 indices with per channel offset. The creation of the per-channel offset can be achieved using the vector immediate. Consider a generic DirectX 10 Pixel Shader instruction in the form of opr4r[ind]r2 and assume that r0-r1 contain the 16 indices packed every other words, and r2-r3 contains source 1 and r4-r5 contain the destination. This instruction can be converted into the following GEN instructions. The corresponding operations are illustrated in Supporting DirectX 10 Pixel Shader Indexing. mov (16) r11.0<1>:w 0x01234567:v// assigning a ramp vector, repeated once mul (16)acc0:wr11.0<0;16,1>:w4:w// expand ramp range to 4 bytes per step mac (16)r10.0<1>:wr0.0<16;8,2>:w32:w// r10 = index*32 + 0|4|…|28|0|4…|28 Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 228 mov (8)a0.0<1>:wr10.0<0;8,1>:w op (8)r4.0<1>:fr[a0.0]<1,0>:fr2.0<0;8,1>:w// Operate on the first half mov (8)a0.0<1>:wr10.8<0;8,1>:w// Index values are off by a reg (32b) op (8)r5.0<1>:fr[a0.0+32]<1,0>:fr3.0<0;8,1>:w// Operate on the second half. Pixel Shader example using vector immediate. Without vector immediate support, such translation has to either use a long sequence of scalar instructions which is very inefficient or use a constant load which requires additional constant to be managed in memory. 7.3.1.2 Supporting OpenGL Vertex Shader Instruction SWZ When an OpenGL Vertex Shader program is converted to run on GEN in Vertex Pair, i.e. two 4-wide vectors in parallel, the special OpenGL Shader instruction SWZ (Swizzle) needs to be emulated. OpenGL SWZ instruction uses an extended swizzle control field that, in addition to the 4-wide full swizzle control, also includes constant 0 and 1 replacement as well as per channel sign reversal. The later two are not supported by the GEN native instruction. The vector immediate can significantly reduce the overhead of emulating such OpenGL instruction. Consider an OpenGL Shader instruction in the form of SWZr1r0.0-zx-1// Expected results: r1.x = 0; r1.y = -r0.z; r1.z = r0.x; r1.w = -1 It can be emulated by the following three GEN instructions. mul(8)r1.0<1>:fr0.xzxz0x1F111F11:v// Constant vector of (1 -1 1 1 1 -1 1 1) mov (1)f0.08b’10011001// Set flag & masked out channels y and z (f0.0)mov(8) r1.0<1>:f 0x000F000F:v// Constant vector of (0 0 0 -1 0 0 0 -1) In case that only 0, 1, -1 channel replacement is used and there is no signed swizzle, it may be emulated in two GEN instructions. This is illustrated by the following example: OpenGL: Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 229 SWZr1r0.0zx-1// Expected results: r1.x = 0; r1.y = r0.z; r1.z = r0.x; r1.w = -1 GEN: mov (1)f0.08b’01100110// Set flag and masked out channels x and w (f0.0)sel (8) r1.0<1>:f r0.yzxy0x000F000F:v// Constant vector of (0 0 0 -1 0 0 0 -1) 7.3.2 Destination Mask for DP4 and Destination Dependency Control The following example demonstrates the use of destination mask mode of floating point dot-product instruction as well as the use of destination dependency control to improve performance (i.e., avoiding unnecessary thread switch due to possible false dependencies). Consider a generic DirectX 10 Vertex Shader macro of matrix-vector product that is implemented on GEN in the pair of 4-component vector mode. The DirectX 10 equivalent Shader instructions are as the following. dp4 r5.x r0 r4 dp4 r5.y r1 r4 dp4 r5.z r2 r4 dp4 r5.w r3 r4 With destination dependency control, the GEN instructions are as the following. The first instruction in the sequence checks for the destination dependency, but does not clear the dependency bit. The subsequent two instructions would do neither of them. The last instruction avoids checking the destination dependency, but at completion, it clears the destination scoreboard. It ensures that the content of the destination register is coherent, if any of the following instructions uses the same register as source. dp4 (8) r5.0<1>.x:f r0.0<4;4,1>:f r4.0<4;4,1>:f {NoDDClr} dp4 (8) r5.0<1>.y:f r1.0<4;4,1>:f r4.0<4;4,1>:f {NoDDClr, NoDDCChk} dp4 (8) r5.0<1>.z:f r2.0<4;4,1>:f r4.0<4;4,1>:f {NoDDClr, NoDDCChk} dp4 (8) r5.0<1>.w:f r3.0<4;4,1>:f r4.0<4;4,1>:f {NoDDChk} Just as a comparison, IF GEN DP4 implies reduction at the destination; additional shifted moves are required to achieve the same results. The corresponding codes are as the following. The lower performance due to the additional three move instruction as well as added back-to-back dependencies shows that why we choose to implement the destination channel replication for floating point DP4. dp4 (8) r5.0<1>.y:f r1.0<4;4,1>:f r4.0<4;4,1>:f mov (1) r5.1<1>:f r8.0<1;1,1>:f dp4 (8) r5.0<1>.z:f r2.0<4;4,1>:f r4.0<4;4,1>:f mov (1) r5.2<1>:f r8.0<1;1,1>:f dp4 (8) r5.0<1>.w:f r3.0<4;4,1>:f r4.0<4;4,1>:f mov (1) r5.3<1>:f r8.0<1;1,1>:f dp4 (8) r5.0<1>.x:f r0.0<4;4,1>:f r4.0<4;4,1>:f Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 230 7.3.3 Null Register as the Destination Null register can be used as the destination for most of the instructions. Here are some example usages.  Null as destination for regular ALU instructions: As all ALU instructions can be configured to update the flag registers using the conditional modifiers, it is not necessary to have a destination register if the programmer only cares about the conditionals of the operation. In that case, a null in the destination operand field saves register space as well as one less dependency checking.  Null as the destination for SEND/STOR instructions: for the send instruction that only send messages out to an external unit and does not require any return data or feedback, a null in the destination register field signifies the case. o One extension of such case is that even though the operation does not have any return values, a return phase with no payload but simply updating the scoreboard flag for a non-null register can provide a signaling mechanism between the thread and the target external unit. One application of this usage is to allow software to manage the coherency of shared memory resources such like the many caches in the system (particularly, valuable for read/write caches). This is not currently the POR for GEN though. 7.3.4 Use of LINE Instruction LINE instruction is specifically designed to speed up floating point vector/matrix computation when a program operates in channel serial. The following example demonstrates how to use LINE instruction to compute Line Equations for DirectX 10 Pixel Shader. In this example, 2 sets of (Cx#, Cy#, Don’t Care, C0#) 4-tuple coefficient vectors are stored in registers R1. R1: Cx0 Cy0 DC Co0 Cx1 Cy1 DC Co1 8 sets of coordinate 2-D vectors (X, Y) are stored in R2 and R3 in the channel serial mode as R2: X0 X1 … X7 R3: Y0 Y1 … Y7 The objective is to compute the following two line equations for each set of 2D coordinate and store the results in R4 and R5 as R4: (X0*Cx0 + Y0*Cy0+Co0) ... (X7*Cx0 + Y7*Cy0+Co0) R5: (X0*Cx1 + Y0*Cy1+Co1) ... (X7*Cx1 + Y7*Cy1+Co1) Example LINE Equations //------------------------------------------------------------------- // Example compute LINE equation in channel serial scenario //------------------------------------------------------------------- line (8) acc:f r1<0;1,0>:f r2<0;8,1>:f// does acc = X# * Cx0 + Co0 mac (8) r4<1>:f r1.1<0;1,0>:f r3<0;8,1>:f// does r4.# = Y# * Cy0 + acc.# line (8) acc:f r1<0;1,0>:f r2<0;8,1>:f// does acc = X# * Cx0 + Co0 mac (8) r4<1>:f r1.1<0;1,0>:f r3<0;8,1>:f// does r4.# = Y# * Cy0 + acc.# Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 231 The next example is to compute homogeneous dot product for OpenGL pixel shader running in Channel Serial. In this example, an original OpenGL PS instruction is like dph R2.x R0 R1 With register remapping, we can store the input coefficient vector R0 in original format in r0, but 8 sets of input coordinate vectors in channel serial format in r2, r3, r4 and r5, and the destination R2.x component in r6. r0: Cx0 Cy0 Cz0 Co0 DC DC DC DC r2: X0 X1 … X7 r3: Y0 Y1 … Y7 r4: Z0 Z1 … Z7 r5: W0 W1 … W7 The objective is to compute the following DPH equations and store the results in r6 as R6: (X0*Cx0+Y0*Cy0+Z0*Cz0+Co0) ... (X7*Cx0+Y7*Cy0+Z7*Cz0+Co0) Example Homogeneous Dot Product in Channel Serial //------------------------------------------------------------------- // Example compute homogeneous dot product in channel serial scenario //------------------------------------------------------------------- line (8) acc:f r0<0;1,0>:f r2<0;8,1>:f// does acc = X# * Cx0 + Co0 mac (8) acc:f r0.1<0;1,0>:f r3<0;8,1>:f// does acc.# = Y# * Cy0 + acc.# mac (8) r6<1>:f r0.2<0;1,0>:f r4<0;8,1>:f// does r6.# = Z# * Cz0 + acc.# 7.3.5 Mask for SEND Instruction Execution mask (upto 16 bits) for the SEND instruction is transferred to the Shared Function. This provides optimized implementation of DirectX Shader instructions. 7.3.5.1 Channel Enables for Extended Math Unit The following example demonstrates how to use the SEND instruction to get service from the Extended Math unit. Let’s consider COS instruction in DirectX 10 in the following form [([!]p0.{select|any|all})] cos[_sat] dest[.mask], [-]src0[_abs][.swizzle] For a SIMD4x2 VS implementation with the following register mappings p0 =>f0.0 src0 =>r0 dest =>r1 The equivalent GEN instruction is as the following [([!]f0.0.{select|any4h|all4h})] SEND (8) r1[.mask]:f m0 [-][(abs)]r0[.swizzle]:f MATHBOX|COS[|SAT] Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 232 If the source swizzle is replication, the message description field can be modified to MATHBOX|COS|SCALAR to take advantage of the fast mode (scalar mode) supported by the Extended Math. The implied move of the SEND instruction is equivalent to the following instruction: MOV (8) m0[.mask]:f [-][(abs)]r0.0[.swizzle]:f {NoMask} For a SIMD16 PS implementation, the register mappings are as the followings p0 =>f0…f3 // in order of R, G, B, A src0 =>r0,r1; r2,r3; r4,r5; r6,r7 dest =>r8,r9; r10,r11; r12,r13; r14,r15 There are several ways to translate the DirectX instruction, depending on the operand/instruction modifiers present in the DirectX instruction. If predicate is not present and the source swizzle is replication, say, src0.y, which is r2-r3, the translation could be as the following instructions send (8) r8:f m0 -(abs)r2:f MATHBOX|COS send (8) r9:f m1 -(abs)r3:f MATHBOX|COS {SecHalf}// use the second half of 8 flag bits mov (16) r10:fr8:f // All destination color chan’s are same mov (16) r12:fr8:f // MOV is faster than most MathBox func’s mov (16) r14:fr8:f // These MOV’s are compressed instructions Notice that instead of issuing Extended Math messages with the same input data, destination color channel replication is performed by the MOV instructions. This is faster for the thread for most cases as many Extended Math functions consume multiple cycles. This also conserves message bus bandwidth as well as the usage of the shared resource – Extended Math. The destination mask in the DirectX 10 instruction indicates which of the r8 to r15 registers are updated. If the source swizzle is not replication, there will be 8 SEND instructions. With predication on, if the predication modifier is p0.select, translation is to take the selected flag register f#. The other predication modifiers ‘.any’ and ‘.all’ are translated into ‘.any4v’ and ‘.all4v’, respectively. Notice that with predication on, it is not required to run all 4 pixels in a subspan in the same way, so no need to enforce .any4h/.any4v. The following example shows the instruction with predication (but without .select modifier). (f0[.any4v|.all4v]) send (8) r8:f m0 -(abs)r2:f MATHBOX|COS (f0[.any4v|.all4v]) send (8) r9:f m1 -(abs)r3:f MATHBOX|COS {SecHalf} (f1[.any4v|.all4v]) mov (16) r10:fr8:f // All destination color chan’s are same (f2[.any4v|.all4v]) mov (16) r12:fr8:f // MOV is faster than most MathBox func’s (f3[.any4v|.all4v]) mov (16) r14:fr8:f // These MOV’s are compressed instructions The same instructions works also for predication with select component modifier. We simply replase f0 to f3 above by the selected flag register, say, f1. The modifier of any4h/all4v would also work. 7.3.5.2 Channel Enables for Scratch Memory The following example demonstrates how to use the SEND instruction to get service from the Data Port for scratch memory access. Let’s consider general instruction in DirectX 10 that uses scratch memory as a source operand [([!]p0.{select|any|all})] add dest[.mask], [-]src0[_abs][.swizzle], [-]src1[_abs][.swizzle] Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 233 For a SIMD4x2 VS implementation with the following register mappings p0 =>f0 src0 =>r0 src1 =>s2 / r10 dest =>r1 In this example, the scratch memory offset is provided by an immediate and a GRF register r10 is used as the intermediate GRF location for spill/fill of scratch buffer accesses. This arithmetic instruction is converted into a Data Port read followed by an arithmetic instruction. mov (8) r3:d r0:d {NoMask}// move scratch base address to be assembled with offset values mov (1) r3.0:d 2*32 {NoMask}// s2 for vertex 0 mov (1) r3.1:d 2*32+16 {NoMask}// s2 for vertex 1 send (8) r10 m0 r3 DATAPORT|RC|READ_SIMD2 [([!]f0.{sel|any4h|all4h})] add (8) r1[.mask]:f [-][(abs)]r0[.swizzle]:f [-][(abs)]r10[.swizzle]:f So if scratch register is the source, there is no need to use the channel enable side band. This is also true for channel-serial PS cases. Now, let’s consider the case when a scratch register is the destination of an instruction. p0 =>f0 src0 =>r0 src1 =>r1 dest =>s2 / r10 We have add (8) m1:f [-][(abs)]r0[.swizzle]:f [-][(abs)]r1[.swizzle]:f mov (8) r3:d r0:d {NoMask}// move scratch base address to be assembled with offset values mov (1) r3.0:d 2*32 {NoMask}// s2 for vertex 0 mov (1) r3.1:d 2*32+16 {NoMask}// s2 for vertex 1 [([!]f0.{sel|any4h|all4h})] send (8) null[.mask] m0 r3 DATAPORT|RC|WRITE_SIMD2 Notice that with a null as the posted destination register, we are able to transfer the [.mask] over the message channel enables. In many cases for scratch memory assess, a write-with-commit is required, therefore, the posted destination register could be r10. Now, let’s consider the PS case when a scratch register is the destination of an instruction. p0 =>f0-f4 src0 =>r0-r7 src1 =>r8-r15 dest =>s16-s23 / r16-r23 When predication is not on (or predication with swizzle control on), we have add (16) m4:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 234 add (16) m6:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f add (16) m8:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f add (16) m10:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f mov (8) r3:d 0x76543210:v {NoMask}// ramp function mul (16) acc0:d r3:d 16 {NoMask}// ramp function add (8) acc0:d acc0:d 64 {NoMask,SecHalf}// ramp function add (16) m2:d acc0:d 2*256 {NoMask}// ramp function send (16) null m1 r3 DATAPORT|RC|WRITE_SIMD16 As there is no bit left from the unit specified descriptor field, the 4 bit mask must be put into the header field in m1, which requires at least two more instructions. Alternatively, or for the case that predication without modifier is on, we can do a read-modify-write. mov (8) r3:d 0x76543210:v {NoMask}// ramp function mul (16) acc0:d r3:d 16 {NoMask}// ramp function add (8) acc0:d acc0:d 64 {NoMask,SecHalf}// ramp function add (16) m2:d acc0:d 2*256 {NoMask}// ramp function send (16) r16 m1 r3 DATAPORT|RC|READ_SIMD16 // read from scratch // some of the following four instructions may be omitted based on [.mask] field [([!]f0.{sel|any4v|all4v})] add (16) r16:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f [([!]f0.{sel|any4v|all4v})] add (16) r18:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f [([!]f0.{sel|any4v|all4v})] add (16) r20:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f [([!]f0.{sel|any4v|all4v})] add (16) r22:f [-][(abs)]r0/2/4/6_BasedOnSwizzle:f [-][(abs)] r8/10/12/14_BasedOnSwizzle:f mov (16) m4:f r16:f {NoMask} mov (16) m6:f r18:f {NoMask} mov (16) m8:f r20:f {NoMask} mov (16) m10:f r22:f {NoMask} send (16) null m1 null DATAPORT|RC|WRITE_SIMD16 {NoMask}// write back to scratch 7.3.6 Flow Control Instructions Unconditional branches are performed through direct manipulation of the 32-bit IP architectural register. For example: mov (1) IP // jump absoluteadd (1) IP IP // jump relative Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 235 Note that jump distances are specified in terms of bytes, as opposed to instruction counts in the case of break, halt, etc. To minimize confusion, an assembler-only instruction ‘jmp ’, where is an immediate term, may be defined which takes an instruction count for a distance. The jmp pseudo-opcode can be mapped to an “add (1) ip ip * 16” instruction. IP is aligned to an 8-byte boundary, thus the 3 LSBs are not maintained in the IP architectural register and should not be relied upon by software. IP, when used as a source operand, reflects the memory address of the instruction in which it is used. The following are examples illustrating the use of IP: add (1) IP4*16// jumps to HERE_1 add (1) IP0x35// jumps to HERE_1 (4 lsb’s don’t-care) HERE_1:HERE_2: add (1) IP -2*16// jumps to HERE_2 ... add (1) IP 0// infinite loopadd (1) IP 0xF// infinite loop ... Note for Assembler: The if/iff/else/while/break instructions identify relative addresses as the targets of an implicit jump associated with the instruction. These are optional in the assembly syntax as the jitter can determine the location of the matching instruction (e.g. matching endif instruction for a given if instruction). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 236 7.3.7 Execution Masking 7.3.7.1 Branching Example. If / Else / EndIf //------------------------------------------------------------------- // Example if/else/endif scenario // “if (r5==r4) ...else ... end-if” //------------------------------------------------------------------- ... cmp.e.f0 (8) null r5 r4// does r5 == r4? (f0) if (8) HERE_1// “if” part - save then update IMASK; // or goto the ‘else’ if all false ... ... HERE_1:// now do the ‘else’ part else (8) HERE_2// “else” part - invert IMASK // or goto the ‘endif’ if all false ... ... HERE_2: endif// “end-if” part – restore IMASK ....// and continue... If it is known that the code has no nested conditionals, a predicate can be used for a lower overhead, more efficient if/else/endif. (One must consider the probability of all channels taking the same branch, and the number of instructions under the if/else blocks as to which conditional method, predicate or mask, is most efficient). Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 237 7.3.7.2 Fast-If Below is an example of a fast-if instruction. For the ‘iff’ instruction, only and iff-endif construct is allowed, as opposed to a if-else-endif. Note that the target address for branching if all enabled channels fail is one instruction beyond the endif, as the ‘iff’ does not push and update the IMask unless the branch is taken for at least one execution channel. Example Fast If //------------------------------------------------------------------- // Example – Fast If //One instruction overhead conditional //------------------------------------------------------------------- ... cmp.e.f0 (8) null r5 r4// any flag update ... (f0)iff (8) HERE_1// “fast-if” – only pushes IMask; // if execution falls through, // else go to HERE_1 ... ... endif// “end-if” part – restores IMask HERE_1: ...// and continue... 7.3.7.3 Cascade Branching As there is no ‘elseif’ instruction, a C-like cascade branching such as if / elseif / else / endif, can be realized using the basic building blocks of if / else / endif as shown in the following example. Notice that two ‘endif’s’ are required in order to pop the IStack correctly. Example. If / Elseif / Else / EndIf //------------------------------------------------------------------- // Example if/elseif/else/endif scenario // “if (r5==r4) ...elseif (r6>r7) else ... end-if” //------------------------------------------------------------------- ... cmp.e.f0 (8) null r5 r4// does r5 == r4? (f0)if (8) HERE_1// “if” part - save then update IMask; // or go to the ‘else’ part if all false ... Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 238 ... HERE_1:// now do the ‘else’ part else (8) HERE_2// “else if” part - invert IMask // or go to the ‘else’ part if all false cmp.g.f0 (8) null r6 r7// is r6 > r7? (f0)if (8) HERE_3// “if” part - save then update IMask; // or go to the ‘else’ part if all false ... ... HERE_3:// now do the ‘else’ part else (8) HERE_4// “else” part - invert IMask // or go to the ‘end-if’ part if all false ... ... HERE_4: endif// “end-if” part – restore IMask for elseif HERE_2: endif// “end-if” part – restore IMask for if .... 7.3.7.4 Compound Branches Compound branches are supported through the ability logically combine flag registers for each intermediate result. Example Compound Branch //------------------------------------------------------------------- // Example: “if (r0 > r1) OR (r2 <= r3)” //------------------------------------------------------------------- ... cmp.g.f0 (8) null r0:d r1:d// r0 > r1? cmp.le.f1 (8) null r2:d r3:d// r2 <= r3? or (1) f0:w f0:w f1:w// combine f0 and f1 (f0) if (8) HERE_1// Can now do normal if/else ... ... HERE_1:endif Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 239 ... Example Compound Branch Using 'Any' or 'All' //------------------------------------------------------------------- // Example: assuming we’re doing a channel-serial vector in r0-r3 // We want to know if all components of the vector are > 0x80 //------------------------------------------------------------------- ... cmp.g.f0 (16) null r0 0x80// r0 > 0x80? cmp.g.f1 (16) null r1 0x80// r1 > 0x80? cmp.g.f2 (16) null r2 0x80// r0 > 0x80? cmp.g.f3 (16) null r3 0x80// r1 > 0x80? (f0.all4v) if (16) HERE_1 ... ...// code executed only for those channels ...// where per-channel r0,r1,r2,r3 all > 0x80 ... HERE_1:endif ...// and continue... 7.3.7.5 Looping Due to GEN’s SIMD-16 architecture, it must support the case of up to 16 loops running in parallel. These must be handled as independent loops, each with its own loop-exit condition which could occur after a different number of loop iterations. To account for each channel’s progress, a 16b loop-mask ‘LMask’ is defined with 1b associated to each execution channel. This mask keeps track of which channels remain active inside a loop block. Basic Do-While Loop Looping illustrates the most basic loop. Two operations must be accomplished before loop entry. (1) Prior to loop entry, there is some subset of enabled channels as dictated by the code sequence prior. In general, the active status of each channel is indicated in the virtual EMask any point in time. These active channels will become the channels over which the loop is run, and LMask must be initialized with the EMask value. (2) Since a given loop may be nested within another loop, the previous LMask & CMask must be saved to the LStack for later restoration upon loop completion. The ‘msave’ instruction performs both the save and update in a single instruction, and thus all loop-blocks should be fronted with a “msave LStack LMask” and “msave LStack CMask” operation. Note that the LMask and CMask share the same mask-stack. Thus, CMask must always be a 1’s-subset of the LMask for proper stack operation. This is the case if CMask is updated to LMask each pass through the loop (see Looping) and through the ‘break’ instruction updating both masks. Each pass through the loop, a loop terminating operation must be evaluated and stored in a flag register. This condition must be evaluated on a channel-by-channel basis as exemplified: cmp.z.f0(8) null r2 d3// any operation that updates a flag Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 240 The result of this operation sets a bit per channel in the specified flag register, which is then used in the ‘while’ instruction. As loops are performed, channels may become disabled as their termination condition is met. ‘While’ termination is determined on a channel-by-channel basis by the logical AND of corresponding bit positions of AMask, CMask and the specified flag. If the result is ‘1’ the channel remains enabled for the next pass of the loop; if ‘0’ the channel is disabled until loop fall-through. The ‘while’ instruction causes the LMask to be updated with the latest result of enabled channels. If any channel remains enabled (LMask != ...000b), an additional pass through the loop is made. Once a channel is terminated for the loop operation, it remains terminated until the loop is complete for all channels. Upon fall through, the ‘while’ instruction causes the previously saved LMask & CMask to be popped from the LStack, enabling execution on the same subset of channels enabled prior to loop entry (unless a channel had been otherwise terminate inside the loop via ‘halt’). Example Basic Loop Construct //-------------------------------------------------- //Example: Basic do-while loop structure //-------------------------------------------------- ... do// save L/CMask & update BEGIN_LOOP: mov (1) CMask LMask{NoMask}// update CMask for this pass ... ... (

)while (8) BEGIN_LOOP// cond. branch // + restores LMask on fall-through ... Do-While Loop with Break A loop may also be terminated for any channel via the ‘break’ instruction. The ‘break’ instruction causes the corresponding bit positions of enabled channels to be cleared in the LMask. If the updated LMask = ...000b, a branch is made to the specified instruction location. An example is shown below in which the ‘break’ is at the same conditional-nesting level as the terminating ‘while’. Its primary value may simply be to support a “do...break.. while (true)” –type structure for a more direct 1:1 translation from higher-level source code. Example Loop Construct With Non-Nested ‘Break’ //------------------------------------------------------------- //Example: While-true loop //------------------------------------------------------------- #define BrkCode(i,d)(i << 16) + d do// save L/CMask & update Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 241 BEGIN_LOOP: mov (1) CMask LMask{NoMask} // update CMask for this pass ... (

)break (8) BrkCode(0,HERE_1)// Restores LMask when all // channels complete loop. ... ... while (8) BEGIN_LOOP// while true HERE_1: ... A break condition may occur from various levels of nested-ifs. This gives rise to the possibility that a the loop may terminate from within nested ‘if’s, and due to the jump inherent in the ‘break’ instruction, the associated ‘endif’s are not encountered to clean-up the IStack as nesting levels are exited. Example Loop Construct With ‘Break’ From Within Nested If’s //------------------------------------------------------------- //Example: General Loop Structure w/ break inside if’s //------------------------------------------------------------- #define BrkCode(i,d)(i << 16) + d do// save L/CMask & update BEGIN_LOOP: mov (1) CMask LMask{NoMask} // update CMask for this pass ... if ... if ... if ... ... (

)break (8) BrkCode(3,HERE_1)// we’re 3 levels deep, so ... endif endif endif ... (

)break (8) BrkCode(0,HERE_1) ... Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 242 while (8) BEGIN_LOOP// cond. branch // + restores C/LMask on fall-through HERE_1: Do-While Loop with Continue A continue instruction ‘cont’ is provided skip to the next iteration of the loop. Because not all channels participating in the loop may be enabled at the time this instruction is executed, some channels may require continuation of the loop. A special mask ‘CMask’ is defined which accounts for channels temporarily disabled for the current loop pass. Since loops may nested, the CMask must be saved and restored around a loop similar to LMask. Since the CMask value within a properly constructed loop is always a subset of the LMask, it can share the LStack for storage, so long as it is pushed after LMask as shown in Looping. This save/restore operations are not required if the loop being entered does not have any occurrence of a continue instruction. Example Do-While with Continue //------------------------------------------------------------- //Example: General Loop Structure w/ basic break and cont. //------------------------------------------------------------- #define ContCode(i,d)(i << 16) + d do// save L/CMask & update BEGIN_LOOP: mov (1) CMask EMask// re-initialize CMask for this pass ... ... (

) cont (8) ContCode(0,HERE_1) ... HERE_1: (

)while (8) BEGIN_LOOP// cond. branch // + restores C/LMask on fall-through ... Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 243 7.3.7.6 Indexed Jump Example Indexed Jump //------------------------------------------------------------------- // Code example shows the use of jmpi to perform a case statement // of any number of options in 3 jumps //------------------------------------------------------------------- .default_execution_size 8 ... jmpi r0<0,1,0>// jump relative, based on r0.a.x // ----- Jump Table ------ jmp HERE_0// redirect for case 0 jmp HERE_1// redirect for case 1 jmp HERE_2// redirect for case 2 jmp HERE_3// redirect for case 3 ... HERE_0:// ... case 0 ... ... jmp DONE HERE_1:// ... case 1 ... ... jmp DONE HERE_2:// ... case 2 ... ... jmp DONE HERE_3:// ... case 3 ... ... DONE: ...// and continue... Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 244 Revision History Revision Number Description Revision Date 1.0 First 2012 OpenSource edition May 2012 §§ Doc Ref #: IHD-OS-V4 Pt 3 – 05 12 5/31/2012 245