OS代写|C++代写|:这是一个通过C++进行pipline模拟的题目，对基础知识的掌握和编程能力要求很高
Pipeline Simulation Project
Please read the general feedback on Project 00 – Warm-up beforestarting on your pipeline simulation. Thanks.Motivation – Modeling and simulation are an essential part ofcomputer architecture. Why? Building hardware is expensive. A maskset for leading edge technology can cost $1 million (or more).Moreover, hardware is hard to probe. So modeling and simulation areimportant for managing costs and verifying behavior. There are manydifferent kinds of simulation ranging from high-level behavior downto the level of individual logic gates. Our projects will be simple,functional, trace-driven simulations. [1]
Project description – Your team should write, document, compile andtest a pipeline simulation program to determine the number of stallcycles needed to avoid RAW hazards due to data dependencies. Therewill be two experiments you should perform with your simulator(described below).
We will make a number of simplifying assumptions: 1) all instructionswill execute in-order and will take the same number of cycles, 2) alloperands will be read at the same stage, 3) all results will be written atthe same stage. Under these restrictions, WAR and WAW hazards willnot occur. This is not realistic, but it will suffice to develop a simplepipeline simulation for our purposes. You are not expected to simulateactual calculations or to move values between registers! Accordingly,you should only model what is necessary for this specific assignment.You should be looking for RAW hazards and inserting stalls / bubblesinto the pipeline as needed.
We will not adhere strictly to a MIPS model. In fact, your simulatorshould be able to model different numbers of pipeline stages (e.g., sayfrom 4 to 10). By running the simulator on the same trace with adifferent number of stages, you should be able to see the effect of thelength of pipeline on stalls per instruction. Your simulator should also
allow for specifying (within bounds) the stages at which operands areread (e.g., ID) and at which results are available (e.g., WB). (Obviously,the read cycle cannot occur after the write cycle.) Varying these valuesmay also have an effect on the number of stalls per instruction.
Your program will read data from a trace file. Each line in the trace filewill have three integer elements. These represent the registers forresult, operand 1, and operand 2. A sentinel value of -1 for any elementmeans that the instruction does not produce a result, or that it doesnot use that operand. There is a set of trace files provided. You can findthese at
http://www.uvm.edu/~cbcafier/assets/cs222-spring-2018/trace.zip
http://www.uvm.edu/~cbcafier/assets/cs222-spring-2018/trace.tar.gz
You should run your simulation against trace files as specified below.Trace files are of two types: Traces that are meant to approximate realworld conditions (these have names starting with gcc) and traces thatare pseudorandom (these have names starting with rand).
You are to use your simulator to conduct two experiments. For the firstexperiment, you should vary input parameters, especially the numberof pipeline stages, when running against traces that have filenamesstarting with gcc, and observe what effect these have on frequency ofstalls. Use files gcc-10k-a.trace and gcc-10k-b.trace for this. For thesecond experiment, you should fix input parameters at five stages, readoperands at stage two, and write at stage five. The pseudorandomtraces vary the number of registers available (you can see this in thefilename). With input parameters fixed, run your simulator against thepseudorandom traces and observe the results.
Output should include the number of cycles taken for the entireinstruction trace, the pipeline speedup, and the average stalls perinstruction. Sample trace and output are shown below. Format ofoutput shown is merely a suggestion, but you should have some kind ofchart or tabular presentation of instructions moving through pipeline,showing where stalls / bubbles occur.
There are many different approaches you can take to this simulation.There is no single correct approach. Of course, your simulation shouldbe an accurate model of the (simplified) pipeline and should accuratelydetect hazards and model stalls.
Language – C++. Use standard libraries. Please do not use any third-party or external libraries. You will not need them and any projectssubmitted that require third-party or external libraries will be rejected.Please try to use best practices for organizing and documenting yourcode. If things dont work as expected, the only way youll get anypartial credit will be if your code is easily readable and well-documented.[2]
Write-up: Presentation and analysis of results – You should include abrief write-up summarizing your findings. Each of the two experimentsshould be addressed separately. A total of one and one-half to twopages should suffice; three pages maximum.
Submission – Submission should include all source code, makefiles,readme, output files, and writeup. You may submit by zipping files intoa single archive and emailing it to me, or you can grant me reporter-level access to a private repo on https://gitlab.uvm.edu.[3] You do notneed to include trace files or binaries in your submission. Everysubmission should include a brief statement of how each teammember contributed to the project (put this in the readme). If you haveset boundaries on inputs, please make a note of it in the readme. Ifthere are any special instructions with regard to build, please includethem in the readme. Please stick to plain text, Markdown or a PDF forthe readme.
Grading – Projects will be graded on a ten-point scale, taking intoconsideration 1) accurate handling of trace input and correct detectionof hazards and simulation of stalls, 2) clarity of output generated byyour program, including execution chart or table, 3) completeness andfollowing instructions / guidelines, and 4) presentation of findings.Partial credit may be given if your code is readable and well-documented.
Due date – Submissions are due Thursday, 5 April by 12:00 noon. Latesubmissions accepted by professor / TA discretion only (read: hand inon-time). Feel free to ask questions. If you want to make a submissionat around the halfway point for some feedback on your progress, thatwould be fine. In fact this is encouraged! Such submissions will not begraded and will not be factored into your project grade, but you will getcomments.
Contact – Email or share with [email protected] Note: If youcorrespond via email on behalf of your team, please cc: all teammembers in your correspondence.
PDF If youd like a PDF, here it is.
Notes
[1] Project definition is based in large part on materials provided byDavid Hathaway, formerly of IBM and University of Vermont, for UVMCS 222, Spring 2016. Trace data labeled gcc are provided by DavidHathaway.
[2] Its a very good idea to include a makefile or instructions forcompiling in the readme. Without these, Ill probably just try g++ [yourcpp filename here] and give up if this doesnt compile.
[3] If you use a source code repository (and I suggest you do), pleaseuse https://gitlab.uvm.edu. Do not make your repo public! You andyour team members should be the only ones with access. Anyone usinga public repo will get a zero. Also, grading will be based only oncommits made before the submission deadline.