help.html

计算机系统结构的讲义,浓缩了一本一千多页的书.真的是好东西.

in which some instructions have pre-specified operands.
Letting this loop start at clock cycle one, as most of the examples
and exercises in the <i>CA:AQA</i> text do, will make it easier to focus on the
loop instructions themselves without worrying about other minor details
such as the dependence between a loop instruction in the first
iteration of a loop and an instruction outside the loop.  It is much
handier to write a separate register initialization file for these
cases.
<p>
See also
<dl>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#codeformat">Formats of Code and Data Files</A>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#registerformat">Format of Register Initialization File</A>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#inputsamples">Sample Input Files</A>
</dl>
<p>
When loading related input files, clicking
the left mouse button on the file selection window for any one of the
related files will highlight these files as a group,
if the related files have the same base name.  Press the "load" button
in the "Load" window to load these files.  When choosing to load a
single file, the contents of the selected file will appear to the right
of the file selection window.
You can load as many files as you wish and switch
between related and single load modes.  When all the files 
are loaded, press the "Done" button to close the "Load" window.  Note that
pressing "Done" directly without pressing "Load" first will result in
no file being loaded.
<p>
The "edit" button can be invoked any time during a simulation session to 
revise the current DLX code and edit the input files.  When the edit window
pops up, the assembly code executed by the current simulation session will
be automatically copied into the edit window.  If a totally new 
assembly file is going to be edited, simply press the "Clean" button
in the edit window to get rid of the old files.   When editing is completed, 
the new file can be directly loaded into <b>dlxview</b> to start another simulation
session by pressing the "Load" button in the edit window.  Before the new
file is actually loaded, a dialog box will ask if any other data file
needs to be loaded first.  If the answer is "No", then the *.d file used in the
current simulation session will be loaded first by default. Once a newly
edited file has been loaded into the simulator through the edit window, 
the current simulation session is interrupted, and the processor is 
reset in order to run the latest loaded file.  With the help of the code editor,
you can change the assembly code being executed at any time and try the
new simulation without leaving the <b>dlxview</b> environment.
<p>
<h3>
<a name="forward">
Step Forward
</a>
</h3>
<p>
If no instruction has entered the pipeline yet,
pressing "step forward" will pop up a window to allow entering the
starting address.  Otherwise, the simulation will continue from
wherever execution previously stopped and execute the next instruction.  The 
clock cycle will always advance to the first stage of the newly processed 
instruction.  
<p>
<h3>
<a name="next">
Next Cycle
</a>
</h3>
<p>
If no instruction has entered the pipeline yet,
pressing "next cycle" will pop up a window to allow entering the starting
address.  Otherwise, the simulation will advance by one clock cycle.
The simulator will not necessarily proceed to the next instruction, because
of pipeline stalls.  Pressing "next cycle" continuously will
show every detail in the simulated pipeline.
<p>
<h3>
<a name="go">
Go
</a>
</h3>
<p>
If no instruction has entered the pipeline yet,
pressing "go" will pop up a window to allow entering the starting address.  
Otherwise, the simulation will continue from wherever execution
previously stopped and will not stop until the execution terminates
naturally.  Do not forget to put a <tt>trap #0</tt> instruction at the end of
the assembly code; otherwise, the simulator will continuously fetch 
new <tt>nop</tt> instructions from the zeroed memory locations proceding the input 
code.
<p>
<h3>
<a name="back">
Step Back
</a>
</h3>
<p>
This button provides the flexibility to back step one instruction and
view the state of the processor at the clock cycle when the last instruction
entered the pipeline.  If more than 1K clock cycles have already been
simulated,  it will take a little while to move the pipeline to an earlier
state.  Be patient!
<p>
<h3>
<a name="prev">
Previous Cycle
</a>
</h3>
<p>
The button provides the flexibility to wrap back the state of 
the processor one clock cycle.   If more than 1K clock cycles have
already been simulated,  it will take a little while to move the pipeline 
to an earlier state.  Be patient!
<p>
<h3>
<a name="reset">
Reset
</a>
</h3>
<p>
The "reset" button allows changing the pipelining mode, the configuration of
the processor, or the input code.
<p>
<h3>
<a name="trace">
Trace
</a>
</h3>
<p>
The "trace" button provides the capability to output an instruction trace
or memory reference trace.  This may be fed into a trace-driven simulator
or the <i>dinero</i> cache simulator later to do further analysis.  
Enter the file name
to save the trace as. The trace will be collected starting from 
the current instruction.  Normally, the trace file is not available until
the current simulation session ends; i.e, the simulation stops naturally or
is interrupted by a reset.   However, when pressing either the "step back"
or "previous cycle" buttons during the simulation, the tracing process is 
stopped automatically to avoid producing garbage wrapped around trace.  
In this case, a trace file containing the information from where 
tracing started to the last instruction will be generated. 
<p>
<h3>
<a name="quit">
Quit
</a>
</h3>
<p>
Terminates the <b>dlxview</b> session.
<p>
<a href="help.html#contents"><i>Return to Contents</i></a>
<p>
<hr>
<p>
<h2>
<a name="pipeline">
Pipeline Modes
</a>
</h2>
<p>
<dl>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#pipeline">Basic Pipeline</A>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#tomasulo">Tomosulo Algorithm</A>
<dd> <IMG ALT="*" SRC="images/ball.gif">
   <A HREF="help.html#scoreboard">Scoreboarding</A>
</dl>
<p>
<h3>
<a name="pipe">
Basic Pipeline
</a>
</h3>
<p>
In the <a href="images/pipe.gif">visualization window</a> for the basic
pipeline, the top half is an instruction and clock cycle table, and the
bottom half can be switched between the block diagram of the DLX
pipeline (see Figure 3.44 in the <i>CA:AQA</i> text) and the datapath of the 
integer unit (see Figure 3.22 in the <i>CA:AQA</i> text).  Each instruction 
entering the pipeline is assigned a unique color.  Instructions of a
particular color listed in the top half of the window
execute in the pipeline stage corresponding to same color.
The window exhibits the pipeline state for one particular clock cycle. This 
clock cycle number is displayed at the lower-right corner of the 
visualization window, and is highlighted by a gray strip in the clock 
cycle table.
<p>
The instruction and clock cycle table are capable of displaying the latest
five instructions simulated by <b>dlxview</b>, with the last row showing the
last instruction entering the pipeline.  The highlighted gray
strip identifies which instruction is in which pipeline stage.
There might be more than five instructions in the pipeline at
any time time; the earlier instructions are wrapped off in this
table.  To determine exactly how many instructions are in the
pipeline, count the number of colored boxes in the bottom
pipeline visualization.
<p>
In the pipeline block diagram, if a floating point functional unit is
fully pipelined, the EX pipe stages for this functional unit will be
drawn as separated boxes.  On the other hand, the multicycle EX stage
of a unpipelined floating point unit is shown as a long box with
internal lines.  The block diagram as a whole is also convenient for
determining which instruction is in which pipeline stage.  For a
pipeline that supports multiple outstanding FP operations, there might
be multiple instructions entering the MEM or WB stage simultaneously.
(It can be proved that for the particular DLX machine described in the
section 3.7 of the <i>CA:AQA</i> text, at most two
instructions will go to the MEM or WB stages at the same time.  This is left
as an exercise for the reader.)
In this case, multiple colors will occupy the MEM and WB boxes
(they should be split in a real implementation).
<p>
The integer datapath 
shows what is happening in the integer datapath.  Nevertheless,
floating point operations are exhibited here also when they are in the
IF and ID stages.  At a particular clock cycle, there might be some
floating point instruction executing or writing their results back
to the register file; they may not appear in the integer datapath.
<p>
When a mux is used for selecting operands, the line connecting the
output and the selected input indicates where the operand came
from.  For example, by examining the input muxes to the ALU, you can
determine whether operands came from the register file, the forwarding
path, or the immediate operand stored in the ID/EX stage-register.  If
an operand is forwarded, it is also easy to trace back to the forwarding source
from the highlighted wires.
<p>
The following is a brief description of the features of the DLX
pipeline defined in the <i>CA:AQA</i> text that are supported by <b>dlxview</b>.
<ol>
<li>Instructions are fetched and decoded sequentially. 
<li>Multiple floating point functional units, either fully pipelined or not,
   can be configured for the processor. However, only one integer unit
   is allowed.  
<li>Branches are resolved at the ID stage. There is one branch delay slot
   after the branch instruction, and branch penalties are reduced by the 
   delayed-branch scheme.   It is up to the compiler or user, whichever 
   provides the DLX code, to make sure the successor instruction of a branch 
   is valid and useful.  If no useful instructions can be found, a <tt>nop</tt>
   instruction should be inserted after the branch in the assembly code. 
<li>There is only one write port to the FP register file.
<li>Four types of hazards are checked for in the ID stage:
   <ol>
   <li>Structural hazards,
   <li>WAR hazards, 
   <li>WAW hazards, and
   <li>FP register file write port conflicts.
   </ol>
</ol>
<p>
Moving branch handling logic from the MEM stage to the ID stage may
cause additional stalls in the pipeline because of data dependences.
Since this hazard is not dlxviewussed in the <i>CA:AQA</i> text, 
the <b>dlxview</b> implementation is briefly explained here. 
The hazard may be viewed by writing a
proper code sequence and testing it with <b>dlxview</b>.  
<ol>
<li>If the operand of a branch is generated by the preceding
   integer ALU instruction, the pipeline will stall for one cycle. After
   that, the operand is forwarded from the EX/MEM stage. The stall 
   might last longer for FP branches in this case, depending on the latency 
   of FP instruction.  
<li>If the operand of a branch is generated by the preceding
   load instruction,  the pipeline will stall for two cycles.  After
   that, the operand is forwarded from the MEM/WB stage.
<li>If the operand of a branch is generated by the 
   load instruction preceding the instruction which precedes the branch
   instruction, the pipeline will stall for one cycle.  After
   that, the operand is forwarded from the MEM/WB stage-register.
</ol>
<p>
<h3>
<a name="tomasulo">
Tomasulo Algorithm
</a>
</h3>
<p>
<a href="images/tom.gif">visualization window</a>
<h3>
<a name="scoreboard">
Scoreboard
</a>
</h3>
<p>
<a href="images/scor.gif">visualization window</a>
<p>
<a href="help.html#contents"><i>Return to Contents</i></a>
<p>
<hr>
<p>
<h2>
<a name="appendix">
Appendix
</a>
</h2>
<p>
<dl>
<dd> <IMG ALT="*" SRC="images/ball.gif">
<a href="help.html#startupformat">Format of a Startup File</a>
<dd> <IMG ALT="*" SRC="images/ball.gif">
<a href="help.html#startupsample">A Sample Startup File</a>
<dd> <IMG ALT="*" SRC="images/ball.gif">
<a href="help.html#codeformat">Formats of Code and Data Files</a>
<dd> <IMG ALT="*" SRC="images/ball.gif">
<a href="help.html#registerformat">Format of Register Initialization File</a>
<dd> <IMG ALT="*" SRC="images/ball.gif">
<a href="help.html#inputsamples">Sample Input Files</a>
</dl>