ECEn 528 Prof. Archibald Lab: Dynamic Scheduling Part A: due Nov. 6, 2018 Part B: due Nov. 13, 2018

Transcription

1 ECEn 528 Prof. Archibad Lab: Dynamic Scheduing Part A: due Nov. 6, 2018 Part B: due Nov. 13, 2018 Overview This ab's purpose is to expore issues invoved in the design of out-of-order issue processors. You wi modify a simuator of the simpe pipeined in-order issue, out-of-order competion processor used in previous abs to mode an out-of-order issue processor using register renaming. There is a god standard for this ab (goddxooo), but you are NOT required to match its execution resuts, or even to simuate a processor with the same features and functionaity. You may choose to mode any processor design you wish, provided that it uses dynamic scheduing and register renaming, and that its timing and execution detais are defensibe and grounded in reaity. In your report for this ab, you wi describe the CPU you ve modeed, and your studies shoud incude some resuts from the god standard for comparison. The CPU Mode of the God Standard At the outset you want to understand the CPU modeed by the god standard code, since your CPU is ikey to be fairy simiar. Here are key hardware structures that it incudes: An instruction window (IW). This is effectivey a shared poo of reservation stations for a functiona units in the processor. Instructions occupy a sot in the IW from the time they are dispatched unti they are abe to issue to a functiona unit and begin execution. A reorder buffer (ROB). This is a FIFO that aows the resuts of instructions that execute out-of-order to be put back into program order, making it possibe to recover from mispredicted branches and to support precise exceptions. Instructions occupy a sot in the ROB from the time they are dispatched unti they commit. A unified physica register fie and a renaming tabe. The register fie is unified because it contains a integer and FP registers. In fact, every entry in the register fie can contain any type of architectura register at any instant. (This is somewhat unreaistic, but it makes it easier to mode.) As we mode it, the DLX ISA has 97 architectura registers (32 ints, 32 foats, 32 doubes, and a FP status bit) so the register fie must incude at east 97 registers, and additiona registers are required for instructions that are currenty in fight. The renaming tabe provides a eve of indirection that maps architectura registers to physica registers. Conceptuay, the renaming tabe has two entries per register: one for the architectura state (the atest vaue written by dispatched instructions), and one for the in-order state (the atest vaue written by retired or committed instructions). The in-order state is used to recover from branch mispredictions and to support precise exceptions. The two entries wi map to the same register if there are no in-fight instructions that modify that register. Each instruction with a destination register requires a dedicated physica register unti it retires, at which point the od in-order register can be reused (on the next cyce). Thus, each in-fight instruction that writes to a resut register requires its own physica register unti it retires. With these operating assumptions, specuation is possibe ony if the physica register fie is arger than the set of architectura registers. A store buffer (SB). Each entry hods an address and a vaue. Each store instruction requires a store buffer entry from the time it is dispatched unti it commits (and is removed from the ROB). This buffer is required because stores are not aowed to specuativey modify the contents of memory. The state transition diagram beow refects the progress of instructions as they execute. States in ower-case do not correspond to pipe stages in the CPU, but rather are ways of tracking how much time was spent in that state whie waiting for the conditions required to advance. A instructions pass through these eight states. Note that the MEM stage has vanished; oads and stores now require two cyces in EX. IF ---> ID ---> IS ---> EX ---> WB ---> wp ---> cr ---> CT The verbose timing output of the simuator directy refects the progress of each instruction through these eight states of execution as we as any stas encountered. 1 of 6

2 The states are defined as foows: IF (instruction fetch). An instruction eaves this state on the cyce it is oaded into the instruction buffer. ID (instruction decode and dispatch). An instruction remains in ID unti it enters the instruction window. At most one instruction can be dispatched per cyce. To eave this state, a of the foowing conditions must be met: 1. The ROB must not be fu. Every instruction (even those with no destination operands) needs a ROB sot. 2. The IW must not be fu. This does not appy if the instruction is a NOP or TRAP. (See discussion beow.) 3. The store buffer must not be fu. (This appies ony if the instruction is a store.) 4. There must be a free physica register, if the instruction has a destination register (incuding register 0). IS (instruction issue). An instruction remains in this state unti it can be issued to a functiona unit to execute. As it is issued, its operands are read. In order for an instruction to eave the IS state, the foowing must be true: 1. A source operands must be avaiabe. 2. If the instruction is a oad, a previous stores must have issued. At most one instruction may be issued per cyce. We wi assume that the physica register fie has enough read ports that they are never a imiting factor. EX (execution). Each instruction is in this state for exacty n cyces, where n is the atency of the functiona unit executing that instruction. WB (register fie update). Each instruction is in this state for exacty one cyce. We wi assume that the physica register fie has one write port for each functiona unit so that write ports are never a imiting factor. wp (wait for previous). Each instruction remains in this state unti a of the preceding instructions have eft the CT state. cr (confict at resoution). Each instruction remains in this state if it is unabe to proceed to commit. (For the current version of the god standard, there are no conditions that wi cause an instruction to wait here.) CT (commit). Each instruction remains in this state for a singe cyce. For an out-of-order machine, counting stas and assigning them to instructions is difficut, because another instruction may be abe to execute or otherwise make progress. In the god standard, stas up to and incuding the ID stage are cacuated in a manner identica to the basic pipeined simuator, but of course there are now more sta conditions to check in ID. After ID, the simuator detects and reports deays to individua instructions. These are reported by the simuator as stas, but in reaity they merey deay the instruction in question and do not sta the entire processor. Modeing In-order Behavior You wi aso need to understand how the code you are given works (to mode in-order behavior), since you wi modify it to refect OoO behavior. The pseudo-code beow describes how the baseine code determines the execution timing of each individua instruction. Parts that must be modified for OoO execution are in bod face. 1. Determine BG cyce: the beginning (reference) cyce just before IF begins 2. Determine IF cyce: is there space for the instruction in the instruction buffer? 3. Determine ID cyce: coud be IF+1, but may sta because ROB, IW, or SB fu, or no physica register 4. Determine IS cyce: is instruction deayed because of RAW, oad-store conficts, or issue width? 5. Determine EX and WB cyces 6. Determine CT cyce: must happen in-order, imited to one instruction per cyce. 7. Update timestamps for resut register, a resources used by instruction 8. Output instruction timing (if in verbose mode) The code you are given cas addstas() for each instruction, and that function incudes WAW and RAW hazard detection ogic which woud happen in the IS state. This code uses timestamps to refect the usage of key resources. Each timestamp represents the cyce number on which the corresponding resource was ast used. In the simpe pipeined mode, the ony resources that must be tracked are register vaues, so just one timestamp is needed for each of the integer registers, each of the foating point registers, and the foating point status bit (which must be treated ike a other registers in tracking data dependencies). The compier shoud not mix foat and doube accesses to the same registers in any code, so we shoud never see a data dependence where the resut register of a foat instruction is then used as part of a doube source operand. This gives us fexibiity in using timestamps: we can use separate sets for foat and doube registers, or we can use the same set of timestamps for both. As each instruction executes, the timestamp associated with the resut register wi aow your code to determine when the resut wi be avaiabe (first via bypassing, then via reguar register access). 2 of 6

3 To detect RAW hazards, the existing code simpy compares the current cyce number with the timestamps of a source operands. If one or more operands wi not be avaiabe when needed, a RAW sta occurs. Each instruction waiting for a vaue may eave IS on the ast EX cyce of the instruction producing that vaue. In other words, if an instruction producing a vaue finishes EX on cyce k, an instruction consuming that vaue can begin its first cyce of EX on cyce k+1. (The case of oads producing the needed vaue woud require specia handing and compicate things if we didn't simpy mode oads as having a two-cyce execution atency.) Stores are a specia case in their RAW hazard checking; the data to be stored is not needed unti the second stage of EX (corresponding to the od MEM stage). This case can be seen in the RAW hazard code that checks the avaiabiity of the second operand. To detect WAW hazards, the code simpy checks the time stamp of the destination register for another pending write. To maintain in-order issue behavior, instructions are prevented from competing the IS stage unti the cyce after the previous instruction did. (You can see from the code that in-order fetch behavior is maintained in the same fashion). For the CPUs modeed in this ab, we assume that a instruction accesses require a singe cyce and that a oads require a fixed atency. The atency of a functiona units is configurabe from the command ine. It is possibe to specify the sizes of the instruction buffer, the instruction window, the reorder buffer, the physica register fie and the store buffer. Two types of branch prediction can be specified as we: no branch prediction, and perfect branch prediction. In the case of no branch prediction, the instruction that foows a branch deay sot wi not begin fetch unti after the branch instruction competes its fina EX cyce. The god simuator aso has a command-ine option teing it to execute in norma pipeined mode rather than in OoO mode. You may find this usefu for comparison in some of your studies. As a fina note about the operation of the baseine simuator, it might prove usefu to understand the specia-case handing for nop and trap instructions. These are the ony two instructions for which the vaue of the funit parameter is NOP_UNIT. Nops reay don't require a separate functiona unit to execute; for our purposes here the essentia characteristic of nops is that they wi never sta the pipeine due to source or destination operands. We coud mode this in the code in various ways; in the baseine code, nops are aocated a sot in the ROB but they do not require a sot in the IW. Conceptuay, each requires a singe execution cyce, but they never produce a resut that other instructions use. Traps are a bit more probematic. In the simuator, ibrary and system cas are impemented by assigning a specific trap instruction to each and then having the simuator perform a the actions required for that function ca in its interna C code when that instruction executes. Thus, individua trap instructions cause quite a bit of work to be done. Since the timing of this work is very unreaistic to begin with, we can afford to take a simpistic approach in modeing trap timing. In effect, we mode them just ike nops in that they wi never cause a pipeine sta. Traps require no source operands but do produce a resut in a destination register (aways reg. 2 because of function return-vaue conventions). We wi ignore this destination register. Likewise, we wi ignore the need for precise exceptions around these traps. Thus, we can treat traps exacty the same as nops. This is the approach taken in the code you are given. The God Standard OoO Mode For out-of-order issue with renaming, the RAW hazard detection ogic is actuay the same as in the in-order case. Our method of using timestamps to track the fow of data works just fine: the timestamp for a register is aways set based on the timing of the ast instruction to write to that register. The WAW hazard detection ogic shoud be removed, since these hazards cannot occur with register renaming. (The god standard incudes a count of WAW hazards, but this shoud aways be zero.) Renaming aso eiminates WAR hazards, but these were not possibe in the in-order pipeine either, so there is no detection ogic for them in the baseine code to begin with. When the out-of-order processor dispatches an instruction, it is inserted into the IW (uness a trap or nop), the ROB, and the store buffer (if it is a store). If the instruction has a destination register, a physica register wi aso be aocated. At most one instruction can be dispatched per cyce. An instruction can be issued from the IW to its functiona unit when its ast source operand becomes avaiabe, but just one instruction can be issued per cyce across a functiona units. An instruction cannot be dispatched and issued in the same cyce since these are separate stages. After executing, an instruction waits in the ROB unti it is the odest entry, at which point it commits. At most one instruction may retire or commit per cyce. Entries in the store buffer are aocated at dispatch and freed at commit. If the store buffer is fu, a new store instruction can be dispatched in the same cyce that the odest store in the buffer is in CT. Loads may not issue unti a preceding stores have issued. A oad can issue in the cyce after the ast oder store issues because the address cacuation for the store is assumed to be cacuated in the first stage of EX and then made avaiabe to the oad for store buffer bypass checking. In effect, we assume that both the vaue and the address of the store wi be entered into the store buffer entry by the end of the first execute cyce. From that cyce on, we assume fu bypassing from the store buffer; this aows the oad to get the data 3 of 6

4 from a conficting store. As a consequence, we don't have to save addresses in the store buffer or compare oad and store addresses, since the access timing is the same whether the vaue is bypassed from the store buffer or not. As noted above, nops and traps use dispatch and commit bandwidth but not issue bandwidth. They are not stored in the instruction window, but they are stored in the reorder buffer. The Existing Code The source code to the simuator can be found in the gzipped tar fie abdynsched.tar.gz in /ee2/ee628/dist. After unzipping and untarring this fie, you wi have a directory named abdynsched. Typing "make" in that directory shoud produce an executabe named "mydx". The ony fie you wi need to modify is sta.c, but you are free to ook through the other fies. To mode your own CPU, you wi want to understand the interface between the code in sta.c and the rest of the simuator. Six functions in sta.c are caed by the code in dx.c: 1. cearsta(). This function is caed each time the simuator begins to execute a program. You shoud modify this function so that a variabes that you use are initiaized (or ceared) for each separate execution. 2. addstas(). This function is caed once for each instruction the simuator executes (in program order). It has severa parameters that te you amost everything you need to know about the current instruction, assuming you have modeed the effects of previous instructions correcty. The code provided as a starting point impements a singe-issue processor. 3. tpressed(). This function is caed each time the user presses the 't' key at the simuator prompt. The function outputs timing information about the most recent execution, incuding tota stas and a breakdown of sta types. 4. ppressed(). This function is caed each time the user presses the 'p' key to the simuator prompt. 5. zpressed(). This function is caed each time the user presses the 'z' key to the simuator prompt. 6. fataerrormsg().this function outputs hepfu information whenever a fata error occurs in the simuator. The code you are given incudes comments that are ikey to be hepfu in modifying the simuator for your own CPU. In particuar it incudes comments (which say TODO ) that indicate portions of code that you are ikey to modify to refect OoO execution. Some of the specific suggestions assume that you are trying to match the god standard. Since this is not required for this ab, you may foow these suggestions or you may take a different approach. The existing code gives you some very usefu functions to dea with timestamps, and you are strongy encouraged to use them, since timestamps are such a critica part of this ab. In sta.c, foowing the extern variabes is a section of code entited stamp buffers. This section of code defines an abstract data type that is simpy an ordered ist of timestamps. Use this data type to create buffers that refect the usage of critica resources in the system. In the god standard, they are used to mode instructions in the IW and the ROB as we as the number of physica registers in use at any instant. You can save yoursef a ot of time in the ong run if you figure out how to use this abstract data type at the outset. The reevant timestamp functions are: insert_stamp (insert a timestamp into a buffer), count_stamp (determine how many stamps exist in a buffer for a particuar cyce), and remove_oder_stamps (remove a timestamps at or before a particuar time). You can find the number of timestamps in the stamp buffer using the occupancy fied. Make sure (1) that you don't reference the odest item in an empty stamp buffer, and (2) that you remove stamps which you can guarantee won't be needed in the future. The atter is reay the key to competing this ab with the functions provided. You wi ikey find it hepfu to see how the existing code uses the timestamp buffers and associated functions to mode the constraints of the instruction buffer. You can see that timestamp refects the cyce during which the instruction eaves the buffer (or, generaizing, finishes with the resource). This makes it possibe to count the number of instructions in the buffer at a given time: it is simpy the instructions which haven't eft by that cyce. We remove instructions once we know that we no onger care about a particuar time. For exampe, once we decide that fetch can't happen any earier than cyce X, we shoud remove a timestamps up to X. Thus, the occupancy fied of the structure indicates how many instructions have timestamps after time X, or how fu the buffer is at time X. Then the check for fetch is simpe: determine the eariest time in which fetch is possibe (one cyce after the previous fetch), remove timestamps oder than that, and see if the buffer is fu. If so, advance the fetch cyce, cearing out stamps oder than the new fetch cyce, unti there is room in the buffer. The god standard uses a simiar approach to mode the store buffer, instruction window, reorder buffer and physica registers. (For the atter, it tracks the current set of renamed registers, effectivey a buffer of renamings which are sti specuative.) Note, for exampe, that you can mode issue width imitations by simpy adding timestamps for the cyce in which issue occurs and removing a timestamps oder than the fetch cyce (since you know that ater instructions that might contend for issue won't be fetched before the current instruction was). 4 of 6

5 Lab Requirements There are two distinct types of timing-reated output that your code shoud generate, but the code to do this is aready in the code you start with. First, to assist in debugging your code, you wi want to output detaied timing information about each instruction. This output wi be simiar to (but need not exacty match) that of the god standard. To generate this output, note that you must concatenate the string indicating the cause of the sta to the stastr variabe; see the code for exampes. Beow is an exampe of the timing output of the god standard (with sight formatting changes to fit this page). Note that it reports a specific cyce for each of the 8 states an instruction must pass through as it executes. From this output, note that the hi instruction executed before the movfp2i instruction which was deayed 4 cyces for a source operand that was produced by the mutipy functiona unit. <pc: dc> mut f0,f0,f1 [ 18 IF+1 ID+1 IS=21 EX+5 WB=27 wp+0 cr+0 CT=28] <pc: e0> movfp2i r24,f0 [ 19 IF+1 ID+1 IS=26 EX+1 WB=28 wp+0 cr+0 CT=29] RAW:(4,mut) <pc: e4> hi r1,0 [ 20 IF+1 ID+1 IS=23 EX+1 WB=25 wp+3 cr+0 CT=30] Secondy, you must generate summary timing output in the tpressed function. This function has aready been fied in for you. Its output shoud be argey sef-expanatory. In comparing your resuts with those of goddxooo, note that it determines the vaue of "Tota cyces" at any point in execution to be one cyce past the maximum IS cyce of any instruction. Aso, you wi notice in the god standard s output that aggregate sta counts may exceed the number of cyces. This is counterintuitive, but it occurs because issue stas are summed on a per-instruction basis and more than one instruction is being considered per cyce. Note aso that stas occurring at dispatch are not counted in totastas; instead, they are counted in dispatchunused. To pass off Part A, submit a copy of your sta.c fie to the instructor, preferaby emaied as an attachment. Your code shoud have reasonabe documentation. In your emai, name students with whom you coaborated, and describe the principa characteristics of the CPU you modeed. To pass off Part B, submit a short (6-7 pages in doube-spaced singe-coumn 11pt mode), we-written report on a study you compete with your simuator and goddxooo (or just goddxooo if you get desperate). At the beginning of your report you shoud describe the CPU you modeed, focusing specificay on key differences in features and functionaity reative to the god standard. You must aso address the important question of how you know your simuator works, since it is unikey to match the god standard. For your study, you are free to choose any topic to investigate, so ong as it reates to out-of-order issue in an obvious way. As recommended in the previous abs, do not be too ambitions in your choice of topic. It is better to pursue one topic in depth than to examine severa topics in a superficia fashion. You coud consider addressing topics such as these: At what point does the performance saturate for various parameters such as buffer sizes? How consistent is performance across avaiabe benchmarks, or across different phases of execution of the same benchmark? What concusions can you make about the efficiency of this CPU reative to a simper pipeined version? Hints and Recommendations The stamp buffers and associated routines are your friends! You can mode a the hardware structures you need by using the stamp buffers. One usefu tidbit: for buffer b, b.odest->prev points to the entry with the argest (newest) stamp. Correcty written code in sta.c wi not affect the operation of the underying simuator, but, thanks to the nature of C code, there are mistakes you can make that wi cause the simuator to mafunction. If, for exampe, the simuator dies at some point in the program other than your own code, or if it just hangs or stops execution before the end of the benchmark you are running, you may understandaby be reuctant to think that your sta.c code is responsibe. However, in every singe case ike this that has turned up so far, the probem can be traced back to incorrect array accesses in sta.c code, in which array bounds are exceeded. Remember, if you write beyond the end of an array in C, the program wi simpy cobber whatever the compier happened to pace in memory after the array, and this can have rather bizarre consequences in the simuator. Trust me: if the simuator is doing something strange, check a of the array accesses in your C code. Use mutipe benchmarks in your testing. test2 can be very hepfu because it very short but has many RAW hazards and a few WAW hazards. Try aso to weed out probems with particuar structures by setting one structure size to something sma and a other structure sizes to arge numbers. This causes the smaer structure to be the imiting factor. 5 of 6

6 Grading Rubrics The report wi count for 70% of your grade and the simuator for 30%. The simuator wi be graded based upon the correctness of its impementation; the instructor may run any number of test cases with your code. The report wi be graded on the foowing items: Eement Possibe Points Ineffective Thesis statement 5 Thesis uncear or ambiguous; does not communicate. Scae and scope 10 Tries to cover too much or too itte; not enough content or too much content. Effective Ceary states the purpose of the study and indicates the hypotheses. Content is we matched to ength imits; topics are adequatey addressed. Support and quaity of thought Arrangement and stye Writing mechanics 10 Weak arguments; unsupported caims; acks understanding of topic. 10 Poor organization; paragraph divisions show itte reason; weak transitions. 15 Incorrect or confusing mechanics frequenty interfere with meaning; distracting accumuation of errors. Evidence supports concusions; no important issues overooked; soid understanding of topic. We-organized with cear sense of direction; good ogica fow; cear, precise meaning. Punctuation, capitaization, speing, and grammar are used consistenty and effectivey to enhance meaning. Data presentation 10 Uncear presentation; unabeed axes; no expanations of graphs; no graphs. Anaysis of data 10 Simpy summarizes the data in textua form; not tied to hypotheses. Data is ceary presented and reader is heped to understand the presentation. Points out unusua aspects of the data; expains the resuts; tied to hypotheses. 6 of 6