COMP 412, Fall 2018 Lab 3: Instruction Scheduling

Transcription

1 COMP 412, Lab 3: Instruction Scheduling Please report suspected typographical errors to the class Piazza site. Code Due date: 11/20/2018 Tutorial #1 Date: tba Submit to: Time: tba Location: tba Report & Due date: 11/27/2018 Tutorial #2 Date: tba Test Block Submit to: Time: tba Location: tba Table of Contents Code 2 C-1 Instruction Scheduling for a Single Basic Block 2 C-2 Code Specifications 3 C-3 Code Submission Requirements 6 C-4 Code Grading Rubric & Honor Code Policy 6 Report & Test Block R-1 Report Contents 7 R-1.1 Questionnaire 7 R-1.2 Results 8 R-2 Test Block 10 R-3 Report & Test Block Submission Requirements 11 R-4 Report & Test Block Grading Rubric & Honor Code Policy 11 Checklist 12 Appendix 13 A-1 ILOC Virtual Machine 13 A-2 ILOC Simulator & Subset 14 A-3 ILOC Input Blocks 15 A-4 Tools 16 A-4.1 Reference Instruction Scheduler 16 A-4.2 Timer 16 A-4.3 Graphviz 17 A-5 Instruction Scheduler Timing Results 18 COMP 412 1

2 Code C-1. Instruction Scheduling for a Single Basic Block This project will expose you to the complications that arise in scheduling instructions for a modern microprocessor. You will design, test, and implement an instruction scheduler that operates on single basic blocks. The goal of your scheduler is to rearrange the instructions in the input block to reduce the number of cycles required to execute the output block, as measured with the Lab 3 ILOC simulator. (See A-2 for details related to the Lab 3 ILOC simulator.) Your scheduler will take as input a file that contains a sequence of operations, expressed in a subset of the ILOC Intermediate Representation (IR) presented in EaC2e. The ILOC subset used in Lab 3 is described in A-2. As output, your scheduler will produce an equivalent sequence of ILOC operations, albeit reordered to improve (shorten) its execution time on the ILOC virtual machine, which is described in A-1. For the purposes of this lab, an input program and an output program are considered equivalent if and only if they print the same values in the same order to stdout and each data-memory location defined by an execution of the input program receives the same value when the output program executes. To simplify matters, the test blocks do not read any input files. All data used by a given test block is contained in the test block or entered on the command line using the ILOC simulator s i option. You have wide latitude in your choice of scheduling algorithms, ranging from a careful implementation of list scheduling through novel techniques of your own invention. See the lecture notes and Chapter 12 (including the chapter notes) of Engineering a Compiler (EAC2e) for descriptions of scheduling algorithms to consider. Your instruction scheduler will undoubtedly build a dependence graph. Many students have found it useful to look at dependence graphs using a visualization tool. We recommend developing your scheduler with an option to output a file that can be visualized using Graphviz ( A-4.3). Code produced by your scheduler must run correctly without hardware interlocks. If the scheduler needs to delay an operation beyond its position in the output block, it must insert the appropriate number of nops, lengthen the schedule, and force the operation into the appropriate cycle. Scheduling is profitable on the ILOC virtual machine because it has two sources of delay that can slow program execution. 1. Some operations have latencies of more than one cycle. If an operation, say in issue slot 3 of the basic block, tries to use the result of an operation in some earlier slot, say slot 2, before the earlier operation completes, then the slot 3 operation may receive an incorrect input value. (Typically, an incorrect input value produces an unexpected and incorrect result.) To ensure correct execution, your scheduler must insert enough nops to ensure that no operation executes before its operands are available. The Lab 3 simulator has options to help you test whether or not your scheduler inserts the right number of nops ( A-2). 2. The ILOC virtual machine has multiple functional units ( A-1). Each unit can execute an idiosyncratic set of operations. If no operation is available to execute on one of the units, then that unit sits idle until the next cycle. For example, if an operation of type fee can execute on either functional unit 0 or 1, and an operation of type foe can only execute on functional unit 1, then the string of operations: fee 1, foe 2, foe 3, foe 4, fee 5, fee 6 COMP 412 2

3 will execute as [ fee 1 ; foe 2 ] [ nop ; foe 3 ] [ fee 5 ; foe 4 ] [ fee 6 ; nop ], where the square brackets indicate a pair of operations that are issued in the same cycle at runtime. A different interleaving of the operations would have avoided the two nops. (For example, swapping the order of foe 4 and fee 5 in the input, if allowed, would eliminate the nops in the output.) Poor operation order can reduce functional unit utilization. Your scheduler can decrease the number of cycles required to execute the output block by reordering operations to reduce the number of nops and increase functional unit utilization. Design and Implementation Timeline: To complete Lab 3 on time, your code should be building a complete and correct dependence graph, including dependences for store, load, and output operations, by Wednesday, November 7, C-2. Code Specifications The COMP 412 teaching assistants (TAs) will use a script to grade Lab 3 code submissions. All grading will be performed on CLEAR, so test your instruction scheduler as well as your makefile and/or script on CLEAR. You must adhere to the following interface specifications to ensure that your instruction scheduler works correctly with the script that the TAs will use to grade your instruction scheduler. Name: The executable version of your instruction scheduler must be named schedule. Behavior: Your scheduler must work in two distinct modes, as controlled by parameters and flags on the command line. Your scheduler must check the correctness of the command-line arguments and produce reasonable and informative error messages when errors are detected. The output described in the table below must be printed to the standard output stream stdout; error messages must be printed to the standard error output stream stderr. The TAs will test both of these modes, using command lines that fit the syntax described below: schedule h When a h flag is detected, schedule must produce a list of valid command-line arguments that includes a description of all commandline arguments required for Lab 3 as well as any additional commandline arguments supported by your schedule implementation. schedule is not required to process command-line arguments that appear after the h flag. schedule <file name> This command will be used to invoke schedule on the input block contained in <file name>. <file name> specifies the name of the input file. <file name> is a valid Linux pathname relative to the current working directory. schedule will produce, as output, an ILOC program that is equivalent to the input program ( C-1), albeit reordered to improve (shorten) its execution time on the ILOC virtual machine ( A-1). The output ILOC code must use the square bracket notation [ op 1 ; op 2 ] described in A-1 to designate operations that should issue in the same cycle. schedule is not required to process command-line arguments that appear after <file name>. COMP 412 3

4 Input: Since input files for Lab 1 and Lab 3 are restricted to the same subset of ILOC instructions, albeit with different latencies assigned to the ILOC instructions ( A-2), you should reuse in your Lab 3 instruction scheduler both your Lab 1 routines for reading ILOC files and your Lab 1 routines for register renaming. If you elect to write a new front end, the following input specifications from Lab 1 apply: o o The input file specified in the command-line argument will contain a single basic block that consists of a sequence of operations written in the ILOC subset described in A-2. If your instruction scheduler cannot read the specified file, or the code in the file is not valid ILOC, your instruction scheduler should produce a reasonable and informative message. If the ILOC code in the input file uses a value from a register that has no prior definition, your instruction scheduler should handle the situation gracefully. Scanning the Input: You must write your own code to scan the input. You may not use a regular expression library or other pattern-matching software, unless you write it. Your code may read an entire line of input and scan that line character-by-character. Note: The timer described in A-4.2 uses input files containing up to 128,000 lines of ILOC. Your scheduler is expected to handle such large files correctly, efficiently, and gracefully. The use of efficient algorithms and data structures in your scheduler is key to handling large input files. Restrictions on Optimizations: Your scheduler must not perform optimizations other than instruction scheduling and register renaming. Assume that the optimizer had a firm basis for not performing other optimizations. Examples of optimizations that will result in loss of credit include: o o o o Removing Dead Code: Your scheduler may remove nops found in the input file; they have no effect on the equivalence of the input and output of programs. Any other operation left in the code by the optimizer is presumed to have a purpose. For example, you may not delete operations that define values that are not used in the test block. Adding ILOC Operations: Your scheduler may add nops. Your scheduler may not add other ILOC operations. For example, your scheduler may not add loadi operations. Folding Constants: You may use constant propagation to disambiguate memory references. You may not use constant propagation to eliminate computations. Optimizing Based on Header Constants: Your scheduler may not rely on input constants specified in test block comments. The COMP 412 TAs are not required to use the input specified in those comments while grading your scheduler. Your scheduler is expected to generate correct code regardless of whether or not the TAs use the input specified in the test block comments. Makefile & Shell Script: Lab 3 submissions written in languages that require a compilation step, such as C, C++, or Java, must include a makefile. 1 (Lab 3 submissions written in languages that do not require compilation, such as Python, do not need a makefile.) The makefile should produce an executable named schedule. Lab 3 submissions written in languages in which it is not possible to create an executable and rename it 1 If you prefer to use a build manager that is available on CLEAR to create your executable, you may invoke that build manager in your makefile. COMP 412 4

5 schedule, such as Python and Java, must include an executable shell script named schedule that correctly accepts the required command-line arguments and invokes the program. For example, a project written in Python named lab3.py could provide an executable shell script named schedule that includes the following instructions: #!/bin/bash python lab3.py $@ A project written in Java with a jar file named lab3.jar or a class named lab3.class that contains the main function could provide, respectively, one of the following two executable shell scripts named schedule: #!/bin/bash java jar lab3.jar $@ #!/bin/bash java lab3 $@ To ensure that your schedule shell script is executable on a Linux system, execute the following command in the CLEAR directory where your schedule shell script resides: chmod a+x schedule To avoid problems related to the translation of carriage return and line feed between Windows and Linux, we recommend that you write your shell script on CLEAR rather than writing it on a Windows laptop and transferring the file. Grading Script: The TA s grading script will first execute a make if a makefile is present. The grading script will then execute commands similar to the following command:./schedule input_block.i > output_block.i This command should invoke your instruction scheduler on a file input_block.i. The output of your instruction scheduler, which has been redirected to output_block.i in the command, will be tested on CLEAR using the Lab 3 simulator. To test your adherence to the interface used by the grading script, run the timer described in A-4.2 on CLEAR. The timer will invoke your schedule executable or script on the timing blocks mentioned in A-3. CLEAR: Your code and makefile/shell script must compile, run, and produce correct output on Rice s CLEAR systems. CLEAR provides a fairly standard Linux environment. Programming Language: You may use any programming language available on Rice s CLEAR facility, except for Perl. To allow you to easily reuse part of your Lab 1 code in Lab 3, you should use the same programming language that you used in Lab 1. README: You are required to submit a README file that provides directions for building and invoking your program. Include a description of all command-line arguments required for Lab 3 as well as any additional command-line arguments that your scheduler supports. To work with the grading scripts, the first two lines in your README file must be in the following form. (Do not include whitespace after //.) //NAME: <your name> //NETID: <your NetID> COMP 412 5

6 Assistance with Lab 3: The COMP 412 staff is available to answer questions: Piazza: Post questions to Piazza, where COMP 412 students, TAs, and professors respond to questions. Tutorial #1: Attend Lab 3 Tutorial #1. COMP 412 staff will be available to answer Lab 3 questions. Tutorial #2: Attend Lab 3 Tutorial #2, which will address instruction scheduler performance issues. Office Hours: Visit the TAs during the hours posted on the Piazza COMP 412 course page under Staff. C-3. Code Submission Requirements Due Date: Lab 3 code is due at 11:59 PM on the code due date (Tuesday, November 20, 2018). Individual extensions to this deadline will not be granted. Early-Submission Bonus: Code received before the code due date will be awarded an additional three points per day up to a maximum of nine points. For example, to receive nine points, you must submit your code by 11:59 PM on Saturday, November 17, Late Penalty: Lab 3 code received after the code due date will lose three points per day. (Late days will not accrue during Thanksgiving Recess (11/22/18 11/25/18).) Late code will be accepted until 5:00 PM on Friday, November 30, Permission from the instructors is required to submit code after this deadline. Contact both instructors by to request permission. Late Penalty Waivers: To cover potential illness, travel, and other conflicts, the instructors will waive up to six days of late penalties per semester when computing your final COMP 412 grade. Submission Details: Create a tar file that contains your submission, including (1) the source code for your instruction scheduler, (2) your makefile and/or shell script, (3) your README file, and (4) any other files that are needed for the TAs to build and test your code. If your scheduler does not work, also include a file named STATUS that describes the current state of the passes in your scheduler (complete/incomplete/not implemented, working/broken, etc.) Name the tar file with your Rice NetID (e.g., jed12.tar for a student with the Rice NetID jed12). the tar file, as an attachment, to comp412code@rice.edu before 11:59 PM on the code due date. Use Lab 3 Code as the subject line of your submission. Note: comp412code@rice.edu should only be used for submitting code since it is only monitored during periods when code is due. Questions should be posted to the COMP 412 Piazza site. C-4. Code Grading Rubric & Honor Code Policy The Lab 3 code grade accounts for 20% of your final COMP 412 grade. The Lab 3 code rubric is based on 100 points, which will be allocated as indicated below. The TAs will award more points to instruction schedulers that produce scheduled ILOC blocks that are correct and efficient, based on the output and cycle count reported by the ILOC simulator for test runs that use as input the Lab 3 report blocks and a set of TA test blocks. At their discretion, the instructors may award partial credit for schedulers with limited functionality. 5 points for adherence to Lab 3 specifications ( C-2) and submission requirements ( C-3). 45 points for the correctness of the code produced by your scheduler. 50 points for the number of cycles required to run the scheduled ILOC code produced by your scheduler on the Lab 3 simulator. Instruction schedulers with aggregate performance scores that are within 5% of the reference scheduler s aggregate performance score will receive 50 points for performance; the remaining instruction schedulers will receive partial COMP 412 6

7 credit. The speed of your scheduler, as measured on the timing blocks (see A-4.2), factors into the lab report grade, not the code grade. Your submitted instruction scheduler source code and README file must consist of code and/or text that you wrote, not edited or copied versions of code and/or text written by others or in collaboration with others. You may not look at COMP 412 code from past semesters. You may not invoke the COMP 412 reference instruction scheduler ( A-4.1), or any other instruction scheduler that you did not write, from your submitted code. You may collaborate with current COMP 412 students when preparing your makefile and/or shell script and submit the results of your collaborative makefile and/or shell script efforts. All other Lab 3 code and text submitted must be your own work, not the result of collaborative efforts. You are welcome to discuss Lab 3 with the COMP 412 staff and with students currently taking COMP 412. You are also encouraged to use the archive of test blocks produced by students in previous semesters. However, you may not make your COMP 412 labs available to students (other than COMP 412 TAs) in any form during or after this semester. In particular, you may not place your code anywhere on the Internet that is viewable by others. Meets Specs Points: The rubric awards 5 points to labs that meet the specifications detailed in C-2 and C-3. Labs that fail to adhere to the specifications will lose points for each infraction; labs with multiple infractions may receive negative meets specs scores. Examples of issues that may result in a loss of points include: Incorrect user interface. ( C-2 under Name and Behavior ) Use of prohibited optimizations. ( C-2 under Optimization ) Broken/missing required makefile and/or shell script. ( C-2 under Makefile & Shell Script ) Missing and/or incorrectly formatted README file. ( C-2 under README ) Broken and/or incorrectly named tar file. ( C-3) Incorrect address or header for submission. ( C-3) Report & Test Block R-1 Report Contents Your Lab 3 report will contain: your replies to a brief questionnaire, two tables of data, and a graph. At the same time, you will submit an original test block that you created to test your scheduler. The specifications for the tables and graph are given in Section R-1.2. The questionnaire should be in a twelve-point font. It can be either single-spaced or double-spaced. The tables and graph should each be on a separate page. R-1.1. Questionnaire The Lab 3 Report Questionnaire will be available on the course web site. It will be provided in both a Microsoft Word format and a plain ASCII file. Run a spelling checker on your questionnaire. COMP 412 7

8 R-1.2. Results The Lab 3 Spreadsheet will be available on the course web site. It will be provided in Excel format. If you need it in another format, please talk to the instructors after lecture. The spreadsheet documents your experimental results, including both the effectiveness and the efficiency of your allocator. It consists of two tables and a chart. The Questionnaire will ask specific questions, based on the data provided in the two tables and the graph. Table 1: Instruction Scheduler Effectiveness: Include a table that lists, for each of the following scenarios, the number of cycles reported by the ILOC simulator for each Lab 3 report block and your ILOC test block: o o Perform instruction scheduling on the blocks using your instruction scheduler, schedule. Use the resulting scheduled blocks as input to the ILOC simulator. (Use the ILOC simulator s -s 1 option.) Perform instruction scheduling on the blocks using the reference instruction scheduler, lab3_ref. (See A-4.1 for a description of the reference instruction scheduler.) Use the resulting scheduled blocks as input to the ILOC simulator. (Use the ILOC simulator s -s 1 option.) Test each report block to verify that the ILOC simulator produces the same output when it is run (1) with the -s 1 option on the scheduled block produced by your instruction scheduler and (2) with the -s 3 option on the original, unscheduled block. Indicate in either your table or in the text if (1) your instruction scheduler failed to produce code for an input block, (2) the ILOC simulator generated an error message when run with your scheduled code for a particular input block, or (3) a block s output when the ILOC simulator is run with the -s 1 option on your scheduled block is different than the block s output when the ILOC simulator is run with the -s 3 option on the original, unscheduled block. Table 1: Total Cycles Required for Lab 3 Report Blocks & Submitted Block * Block schedule lab3_ref Difference schedule lab3_ref Difference Block (cycles) (cycles) (percent) (cycles) (cycles) (percent) report1.i % report13.i % report2.i % report14.i % report3.i % report15.i % report4.i % report16.i % report5.i % report17.i % report6.i % report18.i % report7.i % report19.i % report8.i % report20.i % report9.i % report21.i % report10.i % report22.i % report11.i % report23.i % report12.i % jed12.i % * The simulator runs used to generate the results in this table ran without errors and produced correct output. Table 1 shows the type of information that must be included in your table. The results columns are labeled with the names of the two schedulers being compared: schedule and lab3_ref. Include the results for your instruction scheduler in the two schedule columns. COMP 412 8

9 Compare the number of cycles reported by the simulator for scheduled blocks produced by schedule versus the number of cycles reported for blocks produced by lab3_ref. Report the results in the Table 1 Difference (percent) columns. Use the following formula: 100 * (schedule s cycles lab3_ref s cycles) / (lab3_ref s cycles) Table 2: Instruction Scheduler Efficiency: In a second table, list the results of running the timer described in A-4.2 on CLEAR with your scheduler, schedule. Note instances where the timer did not produce results because your instruction scheduler either required five minutes or more to schedule a smaller file or failed to correctly schedule one or more blocks. Table 2: Scheduler Timing Results * Input (lines) lab3_ref schedule * None of the timing runs generated error messages. Table 2 shows the type of information that must be included in your table. lab3_ref refers to the reference instruction scheduler implementation. schedule refers to the scheduler that you submitted for grading. (The data shown for schedule is from a scheduler written in Java.) Java Programmers: The results presented in Table 2 and its associated graph must be obtained using CLEAR s default JVM maximum heap size. If garbage collection is slowing down your scheduler, you may include supplementary timing data that shows your scheduler s efficiency results for larger maximum heap sizes. Document the maximum heap sizes that you use when measuring the supplementary timings. Graph your scheduler timing results using a format similar to the following graph. To receive full credit, you must use a linear scale (not a logarithmic scale) for both axes of your graph. COMP 412 9

10 Scheduler Timing Results lab3_ref schedule Number of Lines in Input File (thousands) Note: The base points for the Instruction Scheduler Efficiency section of the Lab 3 report are awarded for the inclusion of all requested information and the quality of your responses. The base points are not determined by the speed of your instruction scheduler, as shown in Table 2 and the associated graph. Extra credit points may be awarded for schedule implementations that demonstrate exceptional, reproducible efficiency results when compared to schedule implementations written in the same language (C, C++, Java, Python, etc.). R-2 Test Block You are required to submit an original, commented ILOC test block that either accurately tests one or more aspects of your scheduler, or implements an interesting algorithm or computation. Submitted test blocks may be added to the archive of contributed input blocks ( A-3). Points awarded for your test block will be based on an instructor s evaluation of the quality, correctness, and originality of your ILOC code, and adherence to the following specifications: Your test block must be submitted in a file named with your Rice NetID (e.g., jed12.i for a student with the Rice NetID jed12). Use the.i suffix to indicate that the file contains ILOC. Your test block must produce output (i.e., contain at least one ILOC output statement) that can be used to convincingly determine whether or not the ILOC code executed correctly. The instructors will assess the correctness of your test block with the Lab 1 RunAll script available on CLEAR in /clear/courses/comp412/students/lab1/scripts. To work with the scripts, the first four lines in your test block must be in the following form: //NAME: <your name> //NETID: <your NetID> //SIM INPUT: <required simulator input, for example: -i > //OUTPUT: <expected simulator output, for example: > Do not include whitespace after //. Since the SIM INPUT string specifies input flags and constants (not variable names) that will be used when invoking the simulator, it must be in a form accepted by the simulator. The OUTPUT string must specify the string of integers (not variable names) that the simulator is expected to produce when invoked with your test block COMP

11 and the string specified by //SIM INPUT:. See the blocks described in A-3 for examples of blocks that have comments that meet this specification. Your test block must only use ILOC operations described in A-2. Each ILOC operation must begin on a new line. All memory accesses that occur when your test block is invoked with the input specified in //SIM INPUT: must be word aligned. Additionally, your test block must not use labels, square bracket notation, ILOC pseudo operations, or registers with undefined values. The comments that follow the first four lines of comments must include a brief description of: o The block s input requirements (via the ILOC simulator s -i parameter) and expected output. You can use variables in these comments to describe your block s required input and expected output, as appropriate. o Either the algorithm implemented or the aspect of your scheduler tested by your test block. R-3 Report & Test Block Submission Requirements Your Lab 3 report and test block are due at 11:59 PM on Tuesday, November 27, Individual extensions to this deadline will not be granted. Send your report and test block as attachments to comp412report@rice.edu. Use Lab 3 Report and Test Block as the subject line. Late Penalty: Late Lab 3 reports and test blocks will lose three points per day. Late reports and test blocks will automatically be accepted until 5:00 PM on Friday, November 30, Permission from the instructors is required to submit late Lab 3 reports and test blocks after this deadline. Contact both instructors by to request permission. Late Penalty Waivers: To cover potential illness and conflicts, the instructors will waive up to six days of late penalties per semester when computing your final COMP 412 grade. Priority will be given to waiving penalties for late code over penalties for late lab reports and test blocks. Note: comp412report@rice.edu should only be used for submitting lab reports, test blocks, and test-block-related bug reports since it is not monitored regularly. R-4 Report and Test Block Grading Rubric & Honor Code Policy The Lab 3 report and test block grade accounts for 4% of your final COMP 412 grade. The grading rubric for the Lab 3 report and test block is based on 100 points: 25 points for adherence to the test block specifications in R-3 and the quality, correctness, and originality of the submitted test block. 75 points for adherence to the specifications in R-1, R-2, & R-4 and the grammatical correctness, quality, and content of the resulting lab report. Your submitted ILOC test block and Lab 3 report must consist of code and text that you wrote, not edited or copied versions of test blocks or text written by others. Additionally, when submitting your Lab 3 test block, you may not submit either your Lab 1 test block or a slightly altered version of your Lab 1 test block. The data used to generate the tables and graph required for the report must be produced using the tools and methodology described in R-1.3. You may not submit a test block or report that you jointly wrote with another person. You may not look at COMP 412 reports from past semesters. You may not make your COMP 412 reports available to students in any form during or after this semester. In particular, you may not place your lab report anywhere on the Internet where it is viewable by others. COMP

12 Checklist The following high-level checklist is provided to help you track progress on your Lab 3 code, report, and test block. Implement an instruction scheduler for a single basic block using a scheduling algorithm that you choose or devise ( C-1). Use the Lab 3 ILOC simulator ( A-2) to ensure that the scheduled code produced by your program is correct ( C-1 & C-2) and to measure the number of cycles that the ILOC simulator requires to execute each scheduled block. A variety of ILOC input blocks ( A-3) are available for you to use when testing your instruction scheduler. Test your instruction scheduler on CLEAR. It will be graded on CLEAR. Create an original ILOC test block, as described in R-3. Report the number of cycles required by the ILOC simulator to run both your original test block and the scheduled version of your test block, as described in R-1.3. Report the number of cycles required by the Lab 3 ILOC simulator to run on CLEAR after instruction scheduling each Lab 3 report block, as described in R-1.3. Invoke the timer described in A-4.2 on CLEAR to generate the efficiency data that you are required to include as part of your lab report. Note that you should run the timing tests long before you submit your final code. These blocks provide a useful test of your algorithms and implementation at scale. Submit a lab report and test block following the specifications in sections R-1 through R-5. COMP

13 Appendix A-1. ILOC Virtual Machine The ILOC machine has disjoint address spaces for instructions and data. The Lab 3 simulator ( A-2) provides 200,000 registers, numbered r0 through r199999, and four megabytes of available data memory; accesses to memory must be word aligned. By convention, ILOC input blocks do not access memory addresses above ILOC Microarchitecture. To make the task of scheduling more interesting, the target machine s behavior is more complicated than it was in Lab 1. The ILOC virtual machine has two functional units, f 0 and f 1. These two units are identical, except Only f 0 can execute the load and store operations. Either f 0 or f 1 can execute loadi. Only f 1 can execute the mult operation. Only one output operation can execute per cycle. It can execute on either f 0 or f 1. Thus, most instructions can execute on either functional unit. Only the long latency instructions are constrained to specific functional units. The restriction on output is needed to ensure determinism in the print stream, which is necessary given that your scheduler is required to preserve the ordering among the output instructions. The ILOC machine executes instructions in parallel according to the syntax from Appendix A of EaC2e. Thus, [ op 1 ; op 2 ] is a single instruction containing two operations, op 1 and op 2, that issue concurrently. The order of the operations is not important as long as the machine constraints are not violated. If the second operation of a pair must execute on f 0 and the first can execute on either f 0 or f 1, the dispatch unit will send them to the appropriate units. The machine has several other important quirks. load and store are non-blocking that is, if a load is issued at cycle i, execution continues normally unless the code attempts to execute a reference to the register defined by the load prematurely. Any reference to the result of a load that occurs before the end of its latency that is, before cycle i + 5 for Lab 3 will result in the previous value being used. The store instruction is presumed to execute immediately, although its results do not reach memory until the end of its latency period. Thus, if a store to location p is scheduled in cycle i, and a load from p is scheduled before i + 5, the results are unpredictable and depend on the setting of the stall command line flag (-s). (See the Lab 3 simulator s documentation ( A-2) for details related to the simulator s -s command line flag.) Use the Lab 3 simulator to run some trial ILOC blocks to test the simulator s behavior. The result of a mult instruction is not available before the end of the mult s latency period; attempting to reference it prematurely will result in an incorrect value. In this sense, mult operates in a fashion similar to load. Support For Testing With Interlocks. When you run the original code for a block to determine the correct results, use the simulator s -s 3 option, which is the simulator s default option. This option will ensure that the simulator uses all of the interlocks needed to produce the correct answer. When you test the code produced by your scheduler, use the -s 1 option, which is the option that the TAs will use when they grade your code. (If your code is correctly scheduled, the computed values will be the same as those found with the original code using the -s 3 option.) COMP

14 A-2. ILOC Simulator & Subset ILOC Simulator: An ILOC simulator, its source, and documentation are available on CLEAR. The executable simulator is /clear/courses/comp412/students/lab3/sim. Its source and documentation are in the /clear/courses/comp412/students/lab3/simulator directory. See 7.2 of the simulator documentation for Lab 3 configuration details. The Lab 3 simulator, which is different than the Lab 1 simulator, builds and executes on CLEAR. You can either run the simulator as /clear/courses/comp412/students/lab1/sim, or copy it into your local directory. The simulator appears to work on other OS implementations, but is not guaranteed to work on other OS implementations. Your instruction scheduler will be tested and graded on CLEAR, so you should test it on CLEAR. ILOC Subset: Lab 3 input and output files consist of a single basic block 2 of code written in a subset of ILOC. Your scheduler must support and restrict itself to the following case-sensitive operations: Syntax Meaning Latency load r1 => r2 r2 ß MEM(r1) 5 loadi x => r2 r2 ß x 1 store r1 => r2 MEM(r2) ß r1 5 add r1, r2 => r3 r3 ß r1 + r2 1 sub r1, r2 => r3 r3 ß r1 - r2 1 mult r1, r2 => r3 r3 ß r1 * r2 3 lshift r1, r2 => r3 r3 ß r1 << r2 1 rshift r1, r2 => r3 r3 ß r1 >> r2 1 output x prints MEM(x) to stdout 1 nop idle for one cycle 1 All register names have an initial lowercase r followed immediately by a non-negative integer. Leading zeros in the register name are not significant; thus, r017 and r17 refer to the same register. Arguments that do not begin with r, which appear as x in the table above, are assumed to be non-negative integer constants in the range 0 to Assume a register-to-register memory model (see page 250 in EaC2e) with one class of registers. ILOC test blocks contain commas and assignment arrows, which are composed of an equal sign followed by a greater than symbol, as shown (=>). Each ILOC operation in an input block must begin on a new line. 3 Blanks and tabs are treated as whitespace. ILOC opcodes must be followed by whitespace any combination of blanks or tabs. Whitespace preceding and following all other symbols is optional. Whitespace is not allowed within operation names, register names, or the assignment arrow. A double slash (//) indicates that the rest of the line is a comment and can be discarded. Empty lines and nops in input files may also be discarded. 2 A basic block is a maximal length sequence of straight-line (i.e., branch-free) code. We use the terms block and basic block interchangeably when the meaning is clear. 3 Carriage returns (CR, \r, 0x0D) and line feeds (LF, \n, 0x0A) may appear as valid characters in end-of-line sequences. COMP

15 The syntax of ILOC is described in further detail in Section 3 of the ILOC simulator document, and, at a higher level, in Appendix A of EaC2e. (See the grammar for Operation that starts on p. 726.) Note that your scheduler is not required to support labels on operations. Your scheduler is not required to support square bracket notation in input files, but it must be able to produce output files that use the square bracket notation. Simulator Usage Example: If an input file named test1.i is in your present working directory, you can invoke the simulator on CLEAR on test1.i in the following manner: /clear/courses/comp412/students/lab3/sim -s 3 -i < test1.i This command will cause the simulator to execute the instructions in test1.i, print the values corresponding to ILOC output instructions, and display the total number of cycles, operations, and instructions executed. The -s NUM parameter is optional. It controls the conditions under which the simulator stalls. The default used by the Lab 3 ILOC simulator when it is run without a -s flag is -s 3. When you run the original code for an ILOC test block to determine the correct output results, you should use the default (-s 3 option); when you test the code produced by your Lab 3 scheduler, you should use the -s 1 option. The TAs will use these two flags when they grade the output of your scheduler, so you should use these two flags when you test your scheduler. The -i parameter is used to fill memory, starting at the memory location indicated by the first argument that appears after -i, with the initial values listed after the memory location. The Lab 3 ILOC simulator has byte addressable memory, but the ILOC subset for Lab 1 and Lab 3 only allows word-aligned accesses. So, in the above example, 1 will be written to memory location 2048, 2 to location 2052, and 3 to location (This means that, before the memory locations are overwritten during program execution, "output 2048" will cause 1 to be printed by the simulator, "output 2052" will cause 2 to be printed, etc.) See the ILOC simulator document for additional information about supported command-line options. (Note that the command-line options -d, -r, -x, and -c are not relevant for Lab 3.) A-3. ILOC Input Blocks A collection of ILOC input blocks is available on CLEAR. The comments at the beginning of each input block specify whether or not the input block expects command-line input data via the ILOC simulator s -i parameter. If you experience problems with the input blocks, please submit bug reports to comp412report@rice.edu so that the COMP 412 staff can either fix or delete the problematic blocks. Input Blocks for Lab 3 Report: The Lab 3 report blocks must be used to produce Table 1 for your Lab 3 report, as described in R-1.3. The Lab 3 report blocks are available in: /clear/courses/comp412/students/lab3/report The Lab 1 timing blocks, which will be used by the timer described in A-4.2 to produce timing information for the Lab 3 report, as described in R-1.3, are available in: /clear/courses/comp412/students/lab1/timing Other Available ILOC Input Blocks: Since the ILOC subset used in Lab 1 is the same as the ILOC subset used in Lab 3, you can further test your instruction scheduler by using Lab 1 and Lab 3 ILOC test blocks available on CLEAR in subdirectories of: /clear/courses/comp412/students/lab1 /clear/courses/comp412/students/iloc COMP

16 A-4. Tools A-4.1. Reference Instruction Scheduler To help you understand the functioning of an instruction scheduler for a single basic block and to provide an exemplar for your implementation and debugging efforts, we provide the COMP 412 reference instruction scheduler. The reference instruction scheduler is a C implementation of an instruction scheduler for a single basic block. You can improve your understanding of instruction scheduling by examining its output on small blocks. You will also use the reference instruction scheduler to determine how well your instruction scheduler performs in terms of effectiveness (quality of the schedules that your instruction scheduler generates) and efficiency (runtime of your instruction scheduler). The COMP 412 reference instruction scheduler can be invoked on CLEAR as follows: /clear/courses/comp412/students/lab3/lab3_ref <file name> where <file name> both specifies the name of the input file and is a valid Linux pathname relative to the current working directory. For a description of the flags supported by the COMP 412 reference instruction scheduler, enter the following command on CLEAR: /clear/courses/comp412/students/lab3/lab3_ref -h A script for invoking lab3_ref on a directory of ILOC test blocks is available on CLEAR: /clear/courses/comp412/students/lab3/scripts Note that lab3_ref can only be run on CLEAR and that it does not produce scheduled code for test blocks that use undefined registers. The script will print an error message when lab3_ref detects errors that prevent it from producing scheduled code. The log file generated by the script will contain additional information regarding the nature of the errors detected by lab3_ref. A-4.2. Timer To produce efficiency data for your Lab 3 report, you will use the Lab 3 timer to determine how the runtime performance of your instruction scheduler compares to the runtime performance of the reference instruction scheduler, lab3_ref, over eight timing blocks (T1k.i, T2k.i, T4k.i, T8k.i, T16k.i, T32k.i, T64k.i, and T128k.i). The Lab 3 timer can only be run on CLEAR. To use the timer, copy the tar file on CLEAR available at /clear/courses/comp412/students/lab3/timer.tar into a directory in your own file space on CLEAR. Unpack the tar file. Read the README file. Invoke the timer as follows:./timer <f1> where <f1> specifies the path name of your instruction scheduler (or the shell script that invokes it). The timer assumes that your scheduler accepts the command-line arguments and input described in C-2. <f1> must be a valid Linux pathname relative to the current working directory. The eight timing blocks included in the tar file must appear in the same directory as the timer. Note: The timer will run <f1> on the input files in order from the smallest to the largest file and print timing results when it completes each input file. The timer will quit if your instruction scheduler requires five minutes or more to process a single input file. COMP

17 A-4.3. Graphviz The Graphviz tool is available for various forms of Unix, for Windows, and for the Mac OS from: It is not currently installed on any of the Rice-supported platforms. You can download a copy for your own machine. If this poses a problem, please see the teaching assistants. The point of using Graphviz on small input blocks early in your lab is that it allows you to see the dependence graph and understand it in a way that is hard to achieve with strictly textual output. As secondary benefits, it will provide you with both figures that you can incorporate into your lab report and experience using the kinds of tools that compiler writers use in their work. Graphviz takes as input a dot file a text file that represents, for our purposes, the nodes and edges in a directed graph. Nodes are named with arbitrary integers; edges are named with a pair of numbers joined by an -> operator that specifies the direction of the edge. The full specification of the dot language can be found on the Graphviz web site. For this lab, you will work with a small subset of the dot language. Here is a simple dot file and its output (redrawn in Microsoft Word): digraph testcase1 { 1 [label = "B1"]; 2 [label = "B2"]; 3 [label = "B3"]; 4 [label = "B4"]; 5 [label = "B5"]; 1 -> 2; 2 -> 3; 2 -> 4; 3 -> 5; 4 -> 5; } B3 B1 B2 B5 B4 Input dot File Output Drawing Note that the label field can be arbitrarily long and can include newlines, so that a dot file with the following node specification: 1 [label="add r1 r2 => r3\nr1 ready at cycle 2\nr2 ready at cycle 7\n"]; should produce a node that looks like: add r1 r2 => r3 r1 ready at cycle 2 r2 ready at cycle 7 Using this feature of Graphviz, you can display as much information as you need to understand the graphs that your lab is building. Additional annotations on the nodes can greatly simplify your debugging effort. Note: The use of Graphviz is optional, but strongly recommended for debugging small input blocks. Avoid using Graphviz for large input blocks because it takes significant computational time to produce graphs for large input blocks and, due to the large numbers of nodes involved, the large graphs are difficult to display and decipher. COMP

18 A-5. Instruction Scheduler Timing Results The timing results shown in Figure 1 on page 20 were produced using instruction schedulers submitted by COMP 412 students in Fall 2014 and Fall The featured instruction schedulers all produced correct code and received high scores for both effectiveness and efficiency. These graphs document the most efficient C, C++, Java, Haskell, OCaml, Python, Racket, Ruby, and R implementations submitted and show the expected relative speed differences and the curve shapes for these languages. When discussing the impact of your programming language choice on the efficiency of your instruction scheduler implementation, if your instruction scheduler is written in C, C++, Java, Haskell, OCaml, Python, Racket, Ruby, or R, you are expected to compare your instruction scheduler timing results to the Figure 1 results for instruction scheduler(s) written in your chosen programming language. (See R-1.3.) While direct comparisons with results from past years do not account for software and hardware changes on CLEAR that may have occurred since the results were generated, the observed trends are consistent enough to justify rough comparisons. When viewing the timing results in Figure 1, note the difference in the y-axis scales across the graphs. If your instruction scheduler is written in Java, recall that to judge the asymptotic behavior of a Java program, you need to look at the relationship between runtime and data set size on the large inputs, not the small inputs. COMP

19 C Scheduler Timing Results C++ Scheduler Timing Results Number of Lines in Input File (thousands) Number of Lines in Input File (thousands) Java Scheduler Timing Results Python Scheduler Timing Results Number of Lines in Input File (thousands) Number of Lines in Input File (thousands) Haskell Scheduler Timing Results OCaml Scheduler Timing Results Number of Lines in Input File (thousands) Number of Lines in Input File (thousands) 2015 Ruby Scheduler Timing Results R Scheduler Timing Results Number of Lines in Input File (thousands) Number of Lines in Input File (thousands) 2014 Figure 1: 2014 & 2015 Instruction Scheduler Timing Results COMP