1<html> 2<head> 3<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 4<meta http-equiv="Content-Style-Type" content="text/css"> 5<title>ctr_VertexShaderLinker</title> 6<style type="text/css"> 7<!-- 8body { 9/* 10 font-size : 10pt; 11*/ 12 font-weight : normal; 13 color : #000000; 14 margin : 8px; 15} 16 17div { 18 width : 98%; 19 white-space : nowrap; 20} 21 22div.title { 23 text-align : left; 24 font-weight : bold; 25/* 26 font-size : 16pt; 27*/ 28 font-size : 150%; 29 color : #202020; 30 border-style : double; 31 border-width : 8px; 32 /* タイトルを囲む枠線の色を指定 */ 33 border-color : #CD202C; 34 35 /* RVLプラットフォーム系列 */ 36/* 37 border-color : #34beed; 38*/ 39 40 /* TWLプラットフォーム系列 */ 41/* 42 border-color : #ff458f; 43*/ 44 45 margin : 4px; 46 padding : 4px; 47} 48H1 { 49 font-size : 150%; 50 font-family : Arial; 51 border-bottom-width : 5px; 52 border-bottom-style : solid; 53 border-bottom-color : #CD202C; 54 padding-bottom : 1px; 55 margin-bottom : 20px; 56 letter-spacing : normal; 57 font-weight : bold; 58} 59 60h2 { 61 font-weight : bold; 62/* 63 font-size : 16pt; 64*/ 65 font-size : 150%; 66 border-style : none none solid double; 67 border-width : 0px 0px 2px 8px; 68 /* 見出しの線の色を指定 */ 69 border-color : #CD202C; 70 71 /* RVLプラットフォーム系列 */ 72/* 73 border-color : #34beed; 74*/ 75 76 /* TWLプラットフォーム系列 */ 77/* 78 border-color : #ff458f; 79*/ 80 81 margin-left : 2px; 82 padding-left : 4px; 83} 84h3 { 85 font-weight : bold; 86 font-size : 120%; 87 border-style : none none solid solid; 88 border-width : 0px 0px 2px 2px; 89 border-color : #CD202C; 90 margin-left : 2px; 91 padding-left : 4px; 92} 93CODE { 94 font-family : "Courier New", monospace; 95 position : normal; 96 left : 12px; 97 font-size : 10pt; 98} 99table { 100 margin-top : 2pt; 101 margin-bottom : 2pt; 102 margin-left : 0pt; 103 margin-right : 0pt; 104 padding-left : 0pt; 105 padding-right : 0pt; 106 position : relative; 107 left : 12px; 108 font-family : Arial; 109 font-size : 10pt; 110 border-style : none none none none; 111} 112td,th { 113 padding : 2pt; 114 border-width : 2pt; 115 border-style : none none none none; 116 font-style : normal; 117 text-align : left; 118} 119td { 120 background : #e8f4f4; 121 font-weight : normal; 122} 123th { 124 background : #c0d8d8; 125 font-weight : bold; 126} 127 128p { 129 margin-left : 4px; 130} 131p.code { 132 font-family : "Courier New", monospace; 133 position : normal; 134 left : 12px; 135 font-size : 10pt; 136 background : #e8f4f4; 137} 138 139--> 140</style> 141 142</head> 143<body> 144<a name="top"></a> <!-- ※注意事項 --> <!-- ・(任意)となっているものは、記載が無くても問題ありません。 --> <!-- ・各項目についてる(必須)や(任意)は、作成後に削除してください。 --> <!-- ・各項目内の書き方は、パッケージごとに自由で問題ありませんが、同じパッケージ内で違いがでないようにしてください。 --> <!-- ・タグはすべて小文字、終了タグを持たないものは「/>」で閉じてください。--> <!-- ・HTMLコードのインデントは、各種社内コード規約と同様にスペース4文字か4文字幅のタブになるようにしてください--> 145 146<h1>ctr_VertexShaderLinker</h1> 147 148<h2>Table of Contents</h2> 149<ul style='list-style-type: none'> 150<li>1. <a href="#intro">Introduction</a></li> 151<li>2. <a href="#usage">How to Use</a> 152 <ul style='list-style-type: none'> 153<li>2.1 <a href="#command">Commands</a></li> 154<li>2.2 <a href="#input_file">Input Files</a></li> 155<li>2.3 <a href="#option">Options</a></li> 156 </ul> 157 </li> 158<li>3. <a href="#mapfile_format">Map File Output Feature</a></li> 159 <ul style='list-style-type: none'> 160<li>3.1 <a href="#Loading_objects_order">Loading Objects Order</a></li> 161<li>3.2 <a href="#Image_sizes">Image Sizes</a></li> 162<li>3.3 <a href="#Program_code_information">Program Code Information</a></li> 163<li>3.4 <a href="#Object_information">Object Information</a></li> 164<li>3.5 <a href="#Swizzle_pattern_data">Swizzle Pattern Data</a></li> 165 </ul> 166<li>4. <a href="#consistency_check">Consistency Check Feature</a></li> 167 <ul style='list-style-type: none'> 168<li>4.1 <a href="#end_check">Checks for Execution of an <CODE>end</CODE> Instruction</a></li> 169<li>4.2 <a href="#input_check">Checks Reads from Input Registers</a></li> 170<li>4.3 <a href="#output_check">Checks Writes to Output Registers</a></li> 171 </ul> 172<li>5. <a href="#performance_check">Performance Check Features</a></li> 173 <ul style='list-style-type: none'> 174<li>5.1 <a href="#stall_cause">Detectable Reasons for Stalling</a></li> 175<li>5.2 <a href="#multi_stall">When Multiple Reasons for Stalling Occur</a></li> 176<li>5.3 <a href="#result">Result Output</a></li> 177 </ul> 178<li>6. <a href="#debug_build">Debug Build</a></li> 179<li>7. <a href="#err_code">Error Codes (Linker)</a></li> 180 <ul style='list-style-type: none'> 181<li>7.1 <a href="#err_mes_format">Error Message Format</a></li> 182<li>7.2 <a href="#err_message">Error Message</a></li> 183 </ul> 184<li>8. <a href="#history">Revision History</a></li> 185</ul> 186 187<h2><a name="intro">Introduction</a></h2> 188<P> 189<CODE>ctr_VertexShaderLinker</CODE> links object files output by <CODE>ctr_VertexShaderAssembler</CODE>, and outputs an executable file. 190</P> 191 192<h2><a name="usage">How to Use</a></h2> 193 194<h3><a name="command">Commands</a></h3> 195<p class="code"> 196% ctr_VertexShaderLinker32 <input file name> [options...] 197</p> 198 199<p class="first_ja"> 200Input files must be object files that include at least one <CODE>main</CODE> function. Options can be omitted. Help is displayed if the assembler is executed without any arguments.<BR> 201</p> 202 203<h3><a name="input_file">Input Files</a></h3> 204<p class="first_ja"> 205Specify the object files to be input in place of <input file name>.<BR>If input files include more than one main object, the application must specify the same number of shader objects as there are main objects to the <CODE>glShaderBinary</CODE> function.<BR>All shader objects will access main objects in the order specified by arguments to <CODE>ctr_VertexShaderLinker32</CODE> at this time.<BR> For the file name, specify a string of 128 or fewer characters that contains no spaces, using ASCII alphanumeric characters and any symbols other than the \ / : * ? " < > and | symbols.<br /> 206</p> 207 208<h3><a name="option">Options</a></h3> 209<p class="first_ja"> 210The following options can be specified in place of [options...].<br /> 211</p> 212 213<div class="table"> 214<table border="1" summary="options"> 215<thead> 216<tr> 217<th align="center">Options</th> 218<th align="center">Description</th> 219</tr> 220</thead> 221<tbody> 222<tr> 223<td align="center">-I<file path></td> 224<td align="center">Specifies the file path of the input file.<BR>Input files are looked for in the current directory, and in the order directories are specified using this option.</td> 225</tr> 226<tr> 227<td align="center">-O <File Name></td> 228<td align="center">Specifies the output filename.<BR>The default is "shader.bin".</td> 229</tr> 230<tr> 231<td align="center">-M</td> 232<td align="center">Outputs a map file.<BR>This file has the same name as the executable file, with its extension changed to ".map". See <a href="#mapfile_format">Map File Output Features</a> for more details about map files.</td> 233</tr> 234<tr> 235<td align="center">-debug</td> 236<td align="center">Links all object files with debug information included.</td> 237</tr> 238<tr> 239<td align="center">-nodebug</td> 240<td align="center">Links all object files without including debug information.</td> 241</tr> 242<tr> 243<td align="center">-check_consistency</td> 244<td align="center">Checks the consistency of all main objects being linked.<BR>For details on the consistency check, see <a href="#consistency_check">Consistency Check Feature</a>.</td> 245</tr> 246<tr> 247<td align="center">-check_performance</td> 248<td align="center">Checks the performance of all main objects being linked.<BR>See <a href="#performance_check">Performance Check Features</a> for more information about performance checks.</td> 249</tr> 250<tr> 251<td align="center">-? or -help</td> 252<td align="center">Displays help.</td> 253</tr> 254</tbody> 255</table> 256</div> 257 258<h2><a name="mapfile_format">Map File Output Feature</a></h2> 259<p> 260Information about executable files linked by executing <CODE>ctr_VertexShaderLinker32</CODE> with the <CODE>-M</CODE> option specified. The output file is called a map file.<br>The map file is generated using the same name as the executable file, with the extension changed to ".map".<br><br> The following information is generated: Loading objects order, image sizes, program code information, object information, and swizzle pattern data.<br> 261</p> 262 263<h3><a name="Loading_objects_order">Loading Objects Order</a></h3> 264<p> 265This item shows the order in which main objects have been linked.<BR> The order in which main objects are linked is in the same order that they were specified as arguments to <CODE>ctr_VertexShaderLinker32</CODE>. The order of objects shown here is the same as the order each reference in the shader object was specified by the <CODE>glShaderBinary</CODE> function. The main objects that are debug builds are also shown.<BR> 266</p> 267 268<h3><a name="Image_sizes">Image Sizes</a></h3> 269<p> 270This item shows the size of the linked object files.<BR> "Instruction" represents the number of assembler instructions, and "Swizzle" represents the number of swizzling and masking patterns. (For details, see the heading "Number of Swizzling and Masking Patterns" under "Notes and Limitations."))<br> "Total" represents the total size after linking.<br> 271</p> 272 273<h3><a name="Program_code_information">Program Code Information</a></h3> 274<p> 275This item shows the storage location for program code inside the executable file.<BR> "Program code offset" represents the offset (in bytes) from the start of the file to the address at which program data is stored in the executable file. "Program code size" shows the size (in bytes) of program code data.<BR> 276</p> 277 278<h3><a name="Object_information">Object Information</a></h3> 279<p> 280This item shows the symbol information, output data attribute information, and program start address for each main object that has been linked.<BR> Each of these, respectively, represent settings specified using a <CODE>#pragma bind_symbol</CODE> or <CODE>#pragma output_map</CODE> statement, and the program address set by the <CODE>main</CODE> label.<BR> 281</p> 282 283<h3><a name="Swizzle_pattern_data">Swizzle Pattern Data</a></h3> 284<p> 285This item shows the swizzle pattern data of the executable file.<BR> 286</p> 287 288<h2><a name="consistency_check">Consistency Check Feature</a></h2> 289<p> 290The consistency check feature checks that the assembler has been implemented correctly.<BR> This feature is implemented in the linker and can be enabled by specifying the <CODE>-check_consistency</CODE> option to <CODE>ctr_VertexShaderLinker32.exe</CODE>.<BR> Several items are checked for each main object being linked. The check traverses each instruction in the main object from the <CODE>main</CODE> label up to the <CODE>endmain</CODE> label. A warning is output if an implementation of the item being checked is found.<br><br> Each instruction is checked according to the following conditions.<br> 291<ul> 292<li><CODE>call</CODE> instructions, as well as the source that called them, are checked.</li> 293<li>Conditional jump and conditional call instructions must not branch.<BR> (The branch destinations of <CODE>jpb</CODE>, <CODE>jpc</CODE>, <CODE>callb</CODE>, and <CODE>callc</CODE> instructions are not considered. )</li> 294<li>Both <CODE>if</CODE> and <CODE>else</CODE> instructions are checked for <CODE>ifb</CODE> and <CODE>ifc</CODE> instructions.</li> 295<li>Because an infinite loop results when a subroutine is called recursively by a <CODE>call</CODE> instruction, if the same subroutine is called inside a nested <CODE>call</CODE>, execution proceeds to the next instruction without executing that <CODE>call</CODE>.<BR> (A warning is output in this case.)</li> 296</ul> 297The consistency check checks the items listed below. 298<ul> 299<li>Checks for Execution of an <CODE>end</CODE> Instruction</li> 300<li>Checks Reads from Input Registers</li> 301<li>Checks Writes to Output Registers</li> 302</ul> 303A detailed description of each item is given below. The term "<CODE>if</CODE> instruction" used in this section, includes both <CODE>ifb</CODE> and <CODE>ifc</CODE> instructions.</CODE> 304</p> 305 306<h3><a name="end_check">Checks for Execution of an <CODE>end</CODE> Instruction</a></h3> 307<p> 308This feature checks whether an <CODE>end</CODE> instruction has been called correctly.<br><br> A warning is output for the following checked items.<br> 309<ul> 310<li>When no <CODE>end</CODE> instruction can be found.</li> 311<li>When an <CODE>end</CODE> instruction is found between a pair of <CODE>loop-endloop</CODE> instructions.</li> 312<li>When an <CODE>end</CODE> instruction is found in only one pair of <CODE>if</CODE>-<CODE>else</CODE> or <CODE>else</CODE>-<CODE>endif</CODE> instructions. If no <CODE>else</CODE> instruction corresponds to an <CODE>if</CODE> instruction, a warning is ouput if an <CODE>end</CODE> instruction is found between a pair of <CODE>if-endif</CODE> instructions.</li> 313</ul> 314</p> 315 316<h3><a name="input_check">Checks Reads from Input Registers</a></h3> 317<p> 318This feature checks whether input registers are being used correctly.<BR>This check is performed on the input registers and components specified using a <CODE>#pragma bind_symbol</CODE> statement.<br><br> A warning is output for the following checked items.<br> 319<ul> 320<li>When not all input registers are being used. Any register name and/or component name that is possibly not being used is reported.</li> 321<li>When the way an input register is used differs between <CODE>if-else</CODE> instructions and <CODE>else-endif</CODE> instructions. This is reported because the way in which input registers are used may differ, due to the way <CODE>if</CODE> instructions branch. If no <CODE>else</CODE> instruction corresponds to an <CODE>if</CODE> instruction, a warning is output if an input register is used between a pair of <CODE>if</CODE>-<CODE>endif</CODE> instructions.</li> 322</ul> 323</p> 324 325<h3><a name="output_check">Checks Writes to Output Registers</a></h3> 326<p> 327This feature checks whether output registers are being used correctly.<BR> Output registers specified using <CODE>#pragma output_map</CODE> statements are checked. All xyzw components are also checked.<br><br> A warning is output for the following checked items.<br> 328<ul> 329<li>When not all output registers are written to. Any register name and/or component name that is possibly not being written to is reported.</li> 330<li>When an output register is written to between a pair of <CODE>loop</CODE>-<CODE>endloop</CODE> instructions. This is reported because an output register may be written to more than once, depending on the number of times a <CODE>loop</CODE> instruction repeats.</li> 331<li>When the way an output register is used differs between <CODE>if</CODE>-<CODE>else</CODE> instructions and <CODE>else</CODE>-<CODE>endif</CODE> instructions. This is reported because the way in which output registers are used may differ, due to the way <CODE>if</CODE> instructions branch. If no <CODE>else</CODE> instruction corresponds to an <CODE>if</CODE> instruction, a warning is output if an output register is written to between a pair of <CODE>if</CODE>-<CODE>endif</CODE> instructions.</li> 332<li>When an output register is written more than once. Any register name or component name that may be written to more than once by a given instruction is reported.</li> 333</ul> 334</p> 335 336<h2><a name="performance_check">Performance Check Features</a></h2> 337<p> 338Performance check features include a feature for detecting instructions that cause execution to stall and a feature that estimates the number of clock cycles required per vertex when executing from a shader assembler implementation.<BR> This feature is implemented in the linker, and can be enabled by specifying the <CODE>-check_performance</CODE> option to <CODE>ctr_VertexShaderLinker32.exe</CODE>.<BR> Each main object being linked is checked. The check traverses each instruction in the main object from the <CODE>main</CODE> label up to an <CODE>end</CODE> instruction or <CODE>endmain</CODE> label. Results of the check are output to the file and the command prompt that executed the linker. The output file is generated under the name of the binary file created by the linker, with its extension replaced by "perf.txt." (It is generated in the same location as the binary file.)<br> <br> Each instruction is checked according to the following conditions.<br> 339<ul> 340<li><CODE>call</CODE> instructions, as well as the source that called them, are checked.</li> 341<li>Conditional jump and conditional call instructions must not branch.<BR> (The branch destinations of <CODE>jpb</CODE>, <CODE>jpc</CODE>, <CODE>callb</CODE>, and <CODE>callc</CODE> instructions are not considered. This condition is always determined as FALSE.)</li> 342<li>Only <CODE>else</CODE> instructions are checked for <CODE>ifb</CODE> and <CODE>ifc</CODE> instructions. (This condition is always determined as FALSE.)</li> 343<li>Because an infinite loop results when a subroutine is called recursively by a <CODE>call</CODE> instruction, if the same subroutine is called inside a nested <CODE>call</CODE> instruction, execution proceeds to the next instruction without executing that <CODE>call</CODE> instruction.</li> 344</ul> 345The following items are included in output results.<BR> 346<ul> 347<li>The total number of clock cycles for instructions being executed.</li> 348<li>The total number of instructions being executed.</li> 349<li>Instructions that result in stalling, the number of associated clock cycles, and the cause.</li> 350</ul> 351When calculating the total number of clock cycles, the number of clock cycles that execution is stalled is added as one clock cycle per instruction when a stall occurs.<BR> The reasons output for stalling do not correspond to all of the actual hardware reasons that might result in a stall. Note that the total number of clock cycles calculated should only be used as a guideline, as it does not, necessarily, exactly match the clock cycles executed in actual hardware.<BR> A detailed description of this feature is given below.<BR> 352</p> 353 354<h3><a name="stall_cause">Detectable Reasons for Stalling</a></h3> 355<p> 356You can use this feature to detect several reasons for stalling. A detailed description of each associated item is given below.<BR> 357</p> 358 359<h4>Stalling Due to Instruction Dependencies</h4> 360<p> 361You can detect stalling due to dependency on the register used by an instruction.<BR>Given two instructions where the second instruction references the calculation result of the first instruction, a stall occurs if the second instruction is called before the first instruction has completed its calculation and so must wait (stall) to reference the result.<br><br> The number of clock cycles that execution stalls depends on the latency of the instruction called first and on the number of instructions executed between these two instructions. For details on the latency of each instruction, see <I>Instruction Latency</I>. The register in question may be a temporary register or status register. In the case of status registers, <CODE>ifc</CODE>, <CODE>callc</CODE>, and <CODE>breakc</CODE> may be dependent on <CODE>cmp</CODE>.<br><br>* Example:<br> 362</p> 363<p class="code"> 364dp4 r0 , r1 , r2<br> add r3 , r4 , r0<br> 365</p> 366<p> 367In the example above, the result calculated by <CODE>dp4</CODE> for <CODE>r0</CODE> is used by the <CODE>add</CODE> instruction that immediately follows. Since the latency of <CODE>dp4</CODE> is 5 clock cycles, a stall of 4 clock cycles is the detected result when <CODE>add</CODE> executes.<br><br> Some instructions depend on more than one other instruction. In this case, the number of clock cycles for the instruction with the greatest stall time is used as the stall count for the dependent instruction.<br> <br> Example:<br> 368</p> 369<p class="code"> 370dp4 r0.x , r1 , r2<br> mov r0.y, c0<br> add r3 , r4 , r0<br> 371</p> 372<p> 373In the example above, the third <CODE>add</CODE> instruction depends on both <CODE>dp4</CODE> and <CODE>mov</CODE> for <CODE>r0</CODE>. <CODE>add</CODE> stalls for 3 clock cycles due to <CODE>dp4</CODE> and 1 clock cycle due to <CODE>mov</CODE>. Since the highest stall time of the two is 3 clock cycles, a stall of 3 clock cycles is used as the detected result.<BR> 374</p> 375 376<h4>Stalling Due to Calling the <CODE>mova</CODE> Instruction</h4> 377<p> 378A 3-clock cycle stall results unconditionally when <CODE>mova</CODE> is called. 379</p> 380 381<h4>Stalling Due to Branching</h4> 382<p> 383A 2-clock cycle stall results if the program counter varies by other than +1 due to executing a <CODE>call</CODE> or <CODE>if</CODE> instruction. A 2-clock cycle stall results at the instruction immediately after <CODE>ret</CODE> when execution returns from the source that called <CODE>call</CODE>. 384</p> 385 386<h3><a name="multi_stall">When Multiple Reasons for Stalling Occur</a></h3> 387<p> 388With some instructions, there may be multiple reasons for stalling. In this case, the stall clock cycle count for the reason having the longest stall time is used.<br><br> Example:<br> 389</p> 390<p class="code"> 391main:<br>call label0 // Call to label0<br> ...<br> end<br> <br> label0:<br>dp4 r0.x , r1, r2<br> mova a0.x, r0.x<br> ret<br> 392</p> 393<p> 394In the above example, when the <CODE>mova</CODE> instruction at the end of the subroutine named <CODE>label0</CODE> is reached, a 4-clock cycle stall occurs due to dependence on the immediately preceding <CODE>dp4</CODE> instruction, a 3-clock cycle stall occurs due to calling the <CODE>mova</CODE> itself, and a 2-clock cycle stall occurs due to branching. Since the longest stall time out of all these reasons for stalling is 4 clock cycles, the calculated result is a 4-clock cycle stall. 395</p> 396 397<h3><a name="result">Result Output</a></h3> 398<p> 399Results of the performance checks are output to a file and the command prompt that executed the linker.<BR>The output file is generated under the name of the binary file created by the linker, with its extension replaced by "perf.txt."<br><br> The following content is output to the file:<br> 400</p> 401<p class="code"> 402Main object:obj¥VShader.o<br> <br> Total executed clock count 14 clock<br> Total executed instruction count 7 instructions<br> <br> Detail of stall<br> ============================================================<br> <br> VShader.vsh(26):2 clock stall is caused by branch.<br> <br> VShader.vsh(36):4 clock stall is caused.<br> |<br> +--- 3 clock stall is by mova instruction.<br> |<br> +--- 2 clock stall is by branch.<br> |<br> +--- VShader.vsh(35):4 clock is to wait for this instruction to finish writing r0.<br> <br> VShader.vsh(30):1 clock stall is caused by reading temporary register.<br> |<br> +--- VShader.vsh(29):To wait for this instruction to finish writing r1.<br> ...<br> 403</p> 404<p> 405"Main object" is the name of the main object being checked. Each check result is output for all main objects being linked.<BR> "Total executed clock count" is the total number of clock cycles required for execution per vertex.<BR> "Total executed instruction count" is the number of instructions executed.<BR> The location where a stall occurred, the reason for the stall, and the number of clock cycles that execution stalled are listed under "Detail of stall." In the case of stalling due to instruction dependencies, the location of the instruction being depended upon and the register indicating the reason are shown.<BR>If there is more than one reason for a stall, the stall count for each separate reason and the stall clock cycle count of all results taken together are shown.<br><br> Check results are output in the order instructions are executed, starting from the <CODE>main</CODE> label. If the same subroutine is called more than once, the same stall details are shown multiple times, because a check is made for each instance the subroutine executes.<br><br> Details nearly identical to those output to the file are also output to the command prompt that executed the linker. (Information regarding dependencies is indented.)<br> If the linker is executed from an environment such as Microsoft Visual Studio, you can jump to the shader assembler source file by clicking the output result of a reason for stalling in the output window. This is useful when you want to look at the location of a problem.<br> 406</p> 407 408<h2><a name="debug_build">Debug Build</a></h2> 409<p> 410All assembler objects being linked can be forced to form a debug build by specifying the <CODE>-debug</CODE> option to <CODE>ctr_VertexShaderLinker</CODE>.<BR>All assembler objects being linked can be forced to form a non-debug build by specifying the <CODE>-nodebug</CODE> option to <CODE>ctr_VertexShaderLinker</CODE>.<br><br> If a mixture of debug build and non-debug build assembler objects are linked and even one of the assembler objects referenced by each main object is a debug build, that main object also results in a debug build.<br> 411</p> 412 413<h2><a name="err_code">Error Codes (Linker)</a></h2> 414 415<h3><a name="err_mes_format">Error Message Format</a></h3> 416<P> 417This page describes error messages output by the linker. Errors are output in the following format.<br /><br /> Input file name (line number of error): Error level (error code): Error description<br/> <br /> Errors have an error level of either "warning" or "error." Execution can continue in the case of a "warning" level error. The input file name and/or error line number may not be displayed, depending on the type of error.<BR> <br /> 418</P> 419 420 421<h3><a name="err_message">Error Message</a></h2> 422<P> 423This table gives the error codes output by the linker and their description. 424</P> 425 426<h4><a name="8008xxxx">8008xxxx</a></h4> 427 428<div class="table"> 429<table border="1"> 430<thead> 431<tr> 432<th align="center">Error Code</th> 433<th align="center">Message / Description</th> 434</tr> 435</thead> 436<tbody> 437 438<td align="center" rowspan="2">80080001</td><td> Input file is not specified.</td> 439</tr> 440<tr> 441<td> 442Input file not specified.<BR> 443</td> 444</tr> 445 446<tr> 447<td align="center" rowspan="2">80080005</td><td> “argument” is not found.</td> 448</tr> 449<tr> 450<td> 451Input file could not be found.<BR> 452</td> 453</tr> 454 455<tr> 456<td align="center" rowspan="2">80080006</td><td> Exceeded maximum number of long swizzle masks/patterns.</td> 457</tr> 458<tr> 459<td> 460The number of swizzling patterns for map exceeds the upper limit.<BR> 461</td> 462</tr> 463 464<tr> 465<td align="center" rowspan="2">80080007</td><td> Exceeded maximum number of swizzle masks/patterns.</td> 466</tr> 467<tr> 468<td> 469The number of swizzling patterns exceeds the upper limit.<BR> 470</td> 471</tr> 472 473<tr> 474<td align="center" rowspan="2">8008000f</td><td> Label “label name” is duplicated.</td> 475</tr> 476<tr> 477<td> 478The same label name is defined more than once in the subroutine object.<BR> 479</td> 480</tr> 481 482<tr> 483<td align="center" rowspan="2">80080012</td><td> Cannot open output file.</td> 484</tr> 485<tr> 486<td> 487An executable file could not be generated.<BR> Check whether a read-only file having the same name already exists.<BR> 488</td> 489</tr> 490 491<tr> 492<td align="center" rowspan="2">80080014</td><td> “input file name” is invalid file format.</td> 493</tr> 494<tr> 495<td> 496The input file is not an object file.<BR> 497</td> 498</tr> 499 500<tr> 501<td align="center" rowspan="2">80080015</td><td> Some input files are the same name.</td> 502</tr> 503<tr> 504<td> 505Input files having the same name have been specified.<BR> 506</td> 507</tr> 508 509<tr> 510<td align="center" rowspan="2">8008001d</td><td> “label name” is not subroutine.</td> 511</tr> 512<tr> 513<td> 514An <CODE>ret</CODE> instruction has not been set for a label called as a subroutine by the <CODE>call</CODE> instruction. 515</td> 516</tr> 517 518<tr> 519<td align="center" rowspan="2">8008001f</td><td> “label name” cannot be found in input object files.</td> 520</tr> 521<tr> 522<td> 523The label referenced in the input file cannot be found.<BR> 524</td> 525</tr> 526 527<tr> 528<td align="center" rowspan="2">80080020</td><td> Vertex shader size is over the limit.</td> 529</tr> 530<tr> 531<td> 532The number of instructions in the shader exceeds the upper limit.<BR> Shaders consisting of up to 512 instructions can be linked.<BR> 533</td> 534</tr> 535 536<tr> 537<td align="center" rowspan="2">80080022</td><td> “register name” is duplicately defined in “object name” and “object name”.</td> 538</tr> 539<tr> 540<td> 541A given register is defined as having different values by more than one object through use of the <CODE>def</CODE>, <CODE>defi</CODE>, or <CODE>defb</CODE> instructions.<BR> 542</td> 543</tr> 544 545<tr> 546<td align="center" rowspan="2">80080024</td><td> “register name” is duplicately defined in “object name” and “object name”.</td> 547</tr> 548<tr> 549<td> 550A given output register is mapped to different output data attributes by more than one object through the use of a <CODE>#pragma output_map</CODE> statement.<br /> 551</td> 552</tr> 553 554<tr> 555<td align="center" rowspan="2">80080025</td><td> symbol “symbol name” is duplicately defined in “object name” and “object name”.</td> 556</tr> 557<tr> 558<td> 559A given symbol name is bound to different registers by more than one object through the use of <CODE>#pragma bind_symbol</CODE> definitions. 560</td> 561</tr> 562 563<tr> 564<td align="center" rowspan="2">8008002a</td><td> symbol “symbol name” in “object name” and “symbol name” in “object name” are bound to the same register.</td> 565</tr> 566<tr> 567<td> 568A given symbol in an object is bound to the same input register as another symbol in an object through the use of <CODE>#pragma bind_symbol</CODE> definitions. 569</td> 570</tr> 571 572<tr> 573<td align="center" rowspan="2">8008002b</td><td> “label name” is duplicately defined in “subroutine object name”.</td> 574</tr> 575<tr> 576<td> 577A label name in the main object is also defined in a subroutine object.<BR> 578</td> 579</tr> 580 581<tr> 582<td align="center" rowspan="2">8008002c</td><td> “output data attribute name” is duplicately defined in “object name” and “object name”.</td> 583</tr> 584<tr> 585<td> 586A given output data attribute is mapped to different output registers by more than one object through the use of a <CODE>#pragma output_map</CODE> statement.<br /> 587</td> 588</tr> 589 590<tr> 591<td align="center" rowspan="2">8008002d</td><td> Main routine cannot be found.</td> 592</tr> 593<tr> 594<td> 595An object that includes both <CODE>main</CODE> and <CODE>endmain</CODE> labels is not included among input files.<BR> 596</td> 597</tr> 598 599<tr> 600<td align="center" rowspan="2">8008002e</td><td> Cannot open map file.</td> 601</tr> 602<tr> 603<td> 604A map file cannot be generated.<BR> Check whether a read-only file having the same name already exists.<BR> 605</td> 606</tr> 607 608<tr> 609<td align="center" rowspan="2">8008002f</td><td> No input attribute is defined.</td> 610</tr> 611<tr> 612<td> 613No input attributes are defined.<BR> 614</td> 615</tr> 616 617<tr> 618<td align="center" rowspan="2">80080030</td><td> No output map is defined.</td> 619</tr> 620<tr> 621<td> 622No output attributes are defined.<BR> 623</td> 624</tr> 625 626<tr> 627<td align="center" rowspan="2">80080031</td><td> -debug and -nodebug cannot be specified together.</td> 628</tr> 629<tr> 630<td> 631The <CODE>-debug</CODE> and <CODE>-nodebug</CODE> options cannot be specified at the same time. 632</td> 633</tr> 634 635<tr> 636<td align="center" rowspan="2">80080032</td><td> def(bi) in ***.obj and bind_symbol in ***.obj specify the same register **.</td> 637</tr> 638<tr> 639<td> 640The same register cannot be defined by both a <CODE>def</CODE> instruction and <CODE>bind_symbol</CODE>. 641</td> 642</tr> 643 644<tr> 645<td align="center" rowspan="2">80080033</td><td> texture1 and texture2 need to be mapped to same register, if 4 textures are mapped.</td> 646</tr> 647<tr> 648<td> 649If four textures have been defined using an output_map statement, texture1 and texture2 must be mapped to the same register.<BR> 650</td> 651</tr> 652 653</tbody> 654</table> 655</div> 656 657 658<h4><a name="4009xxxx">4009xxxx</a></h4> 659 660<div class="table"> 661<table border="1"> 662<thead> 663<tr> 664<th align="center">Error Code</th> 665<th align="center">Message / Description</th> 666</tr> 667</thead> 668<tbody> 669 670<tr> 671<td align="center" rowspan="2">40090001</td><td> end instruction is not found.</td> 672</tr> 673<tr> 674<td> 675An <CODE>end</CODE> instruction could not be found. 676</td> 677</tr> 678 679<tr> 680<td align="center" rowspan="2">40090002</td><td> end instruction is found in loop statement.</td> 681</tr> 682<tr> 683<td> 684An <CODE>end</CODE> instruction was found between a pair of <CODE>loop-endloop</CODE> instructions. 685</td> 686</tr> 687 688<tr> 689<td align="center" rowspan="2">40090003</td><td> end instruction is found in only one of if and else statement.</td> 690</tr> 691<tr> 692<td> 693An <CODE>end</CODE> instruction was found in only one pair of <CODE>if-else</CODE> and <CODE>else-endif</CODE> statements. 694</td> 695</tr> 696 697<tr> 698<td align="center" rowspan="2">40090004</td><td> input register "label name" is not used.</td> 699</tr> 700<tr> 701<td> 702The input register defined in a <CODE>#pragma bind_symbol</CODE> statement may not be usable.<BR> 703</td> 704</tr> 705 706<tr> 707<td align="center" rowspan="2">40090005</td><td> The access patterns of input registers are different between if and else statement.</td> 708</tr> 709<tr> 710<td> 711The input register being used differs between a pair of <CODE>if-else</CODE> and a pair of <CODE>else-endif</CODE> statements. 712</td> 713</tr> 714 715<tr> 716<td align="center" rowspan="2">40090006</td><td> output register "register name" is not set.</td> 717</tr> 718<tr> 719<td> 720The output register defined by a <CODE>#pragma output_map</CODE> statement may not be written.<br /> 721</td> 722</tr> 723 724<tr> 725<td align="center" rowspan="2">40090007</td><td> output register is set in loop statement.</td> 726</tr> 727<tr> 728<td> 729The output register is written to between a pair of <CODE>loop-endloop</CODE> statements. 730</td> 731</tr> 732 733<tr> 734<td align="center" rowspan="2">40090008</td><td> The access patterns of output registers are different between if and else statement.</td> 735</tr> 736<tr> 737<td> 738The output register being written differs between a pair of <CODE>if-else</CODE> and a pair of <CODE>else-endif</CODE> statements. 739</td> 740</tr> 741 742<tr> 743<td align="center" rowspan="2">40090009</td><td> output register "register name" is already set before.</td> 744</tr> 745<tr> 746<td> 747The output register is being written to more than once.<BR> 748</td> 749</tr> 750 751<tr> 752<td align="center" rowspan="2">4009000a</td><td> Recursive call is found, and skipped.</td> 753</tr> 754<tr> 755<td> 756A subroutine is being called recursively. The <CODE>call</CODE> statement causing the subroutine to be called recursively is skipped by the consistency check feature.<BR> 757</td> 758</tr> 759 760<tr> 761<td align="center" rowspan="2">4009000b</td><td> Cannot open file for performance report.</td> 762</tr> 763<tr> 764<td> 765A file for storing output results of the performance check feature cannot be created.<BR> 766</td> 767</tr> 768 769<tr> 770<td align="center" rowspan="2">4009000c</td><td> mova instruction both before and after returning from subroutine might cause hardware hang-up.</td> 771</tr> 772<tr> 773<td> 774A malfunction may occur if a <CODE>mova</CODE> instruction occurs both immediately before and after a subroutine called by the <CODE>call</CODE>, <CODE>callb</CODE>, or <CODE>callc</CODE> instructions.<BR> See "Malfunctions Caused by the mova Instruction."<BR> 775</td> 776</tr> 777 778</tbody> 779</table> 780</div> 781 782<h2><a name="history">Revision History</a></h2> 783 <dl class="history"> 784 <dt>2012/01/31</dt> 785<dd>Corrected the error code messages for error codes 800800{22, 24, 25, 2b, 2c}. <br /> 786 </dd> 787 <dt>2011/12/20</dt> 788 <dd>Initial version.<br /> 789 </dd> 790 </dl> 791<hr><p>CONFIDENTIAL</p></body> 792</html>