Medial axis: Difference between revisions
en>EmausBot m r2.7.2+) (Robot: Adding ca:Eix mitjà |
→External links: added link to 'intuitive explanation...' for non mathamaticians |
||
Line 1: | Line 1: | ||
'''Scoreboarding''' is a centralized method, used in the [[CDC 6600]] [[computer]], for dynamically scheduling a [[Pipeline (computing)|pipeline]] so that the instructions can [[Out-of-order execution|execute out of order]] when there are no conflicts and the hardware is available.<ref>{{cite conference | |||
| title =Parallel operation in the control data 6600 | |||
| first = James E. | |||
| last = Thornton | |||
| year = 1965 | |||
| conference = AFIPS '64 | |||
| booktitle = Proceedings of the October 27–29, 1964, fall joint computer conference, part II: very high speed computer systems | |||
| publisher = ACM | |||
| location = San Francisco, California | |||
| pages = 33–40 | |||
| doi = 10.1145/1464039.1464045 | |||
}}</ref> In a scoreboard, the [[data dependency|data dependencies]] of every instruction are logged. Instructions are released only when the scoreboard determines that there are no conflicts with previously issued and incomplete instructions. If an instruction is stalled because it is unsafe to continue, the scoreboard monitors the flow of executing instructions until all dependencies have been resolved before the stalled instruction is issued. | |||
== Stages == | |||
Instructions are decoded in order and go through the following four stages. | |||
# '''Issue''': The system checks which registers will be read and written by this instruction. This information is remembered as it will be needed in the following stages. In order to avoid output dependencies ([[Data_dependency#Output_dependency|WAW]] - Write after Write) the instruction is stalled until instructions intending to write to the same register are completed. The instruction is also stalled when required functional units are currently busy. | |||
# '''Read operands''': After an instruction has been issued and correctly allocated to the required hardware module, the instruction waits until all operands become available. This procedure resolves read dependencies ([[Data dependency#RAW - Read After Write|RAW]] - Read after Write) because registers which are intended to be written by another instruction are not considered ''available'' until they are actually written. | |||
# '''Execution''': When all operands have been fetched, the functional unit starts its execution. After the result is ready, the scoreboard is notified. | |||
# '''Write Result''': In this stage the result is about to be written to its destination register. However, this operation is delayed until earlier instructions—which intend to read registers this instruction wants to write to—have completed their ''read operands'' stage. This way, so called data dependencies ([[Data dependency#WAR - Write After Read|WAR]] - Write after Read) can be addressed. | |||
== Data structure == | |||
To control the execution of the instructions, the scoreboard maintains three status tables: | |||
* '''Instruction Status''': Indicates, for each instruction being executed, which of the four stages it is in. | |||
* '''Functional Unit Status''': Indicates the state of each functional unit. Each function unit maintains 9 fields in the table: | |||
** Busy: Indicates whether the unit is being used or not | |||
** Op: Operation to perform in the unit (e.g. MUL, DIV or MOD) | |||
** F<sub>i</sub>: Destination register | |||
** F<sub>j</sub>,F<sub>k</sub>: Source-register numbers | |||
** Q<sub>j</sub>,Q<sub>k</sub>: Functional units that will produce the source registers F<sub>j</sub>, F<sub>k</sub> | |||
** R<sub>j</sub>,R<sub>k</sub>: Flags that indicates when F<sub>j</sub>, F<sub>k</sub> are ready | |||
* '''Register Status''': Indicates, for each register, which function unit will write results into it. | |||
== The algorithm == | |||
The detailed algorithm for the scoreboard control is described below: | |||
<code> | |||
'''function''' issue(''op'', ''dst'', ''src1'', ''src2'') | |||
wait until (!Busy[FU] AND !Result[''dst'']); // FU can be any functional unit that can execute operation ''op'' | |||
Busy[FU] ← Yes; | |||
Op[FU] ← ''op''; | |||
F<sub>i</sub>[FU] ← ''dst''; | |||
F<sub>j</sub>[FU] ← ''src1''; | |||
F<sub>k</sub>[FU] ← ''src2''; | |||
Q<sub>j</sub>[FU] ← Result[''src1'']; | |||
Q<sub>k</sub>[FU] ← Result[''src2'']; | |||
R<sub>j</sub>[FU] ← not Q<sub>j</sub>; | |||
R<sub>k</sub>[FU] ← not Q<sub>k</sub>; | |||
Result[''dst''] ← FU; | |||
'''function''' read_operands(''FU'') | |||
wait until (R<sub>j</sub>[''FU''] AND R<sub>k</sub>[''FU'']); | |||
R<sub>j</sub>[''FU''] ← No; | |||
R<sub>k</sub>[''FU''] ← No; | |||
'''function''' execute(''FU'') | |||
// Execute whatever ''FU'' must do | |||
'''function''' write_back(''FU'') | |||
wait until (<math>\forall</math>f {(F<sub>j</sub>[f]≠F<sub>i</sub>[''FU''] OR R<sub>j</sub>[f]=No) AND (F<sub>k</sub>[f]≠F<sub>i</sub>[''FU''] OR R<sub>k</sub>[f]=No)}) | |||
foreach f do | |||
if Q<sub>j</sub>[f]=''FU'' then R<sub>j</sub>[f] ← Yes; | |||
if Q<sub>k</sub>[f]=''FU'' then R<sub>k</sub>[f] ← Yes; | |||
Result[F<sub>i</sub>[''FU'']] ← 0; | |||
Busy[''FU''] ← No; | |||
</code> | |||
== Remarks == | |||
The scoreboarding method must stall the issue stage when there is no functional unit available. In this case, future instructions that could potentially be executed will wait until the structural hazard is resolved. Some other techniques like [[Tomasulo algorithm]] can avoid the structural hazard and also resolve WAR and WAW dependencies with [[Register renaming]]. | |||
== See also == | |||
* [[Instruction level parallelism]] | |||
* [[Tomasulo algorithm]] | |||
* [[Out-of-order execution]] | |||
== References == | |||
{{reflist}} | |||
== External links == | |||
*[http://www.cs.umd.edu/class/fall2001/cmsc411/projects/dynamic/scoreboard.html Dynamic Scheduling - Scoreboard] | |||
* ''Computer Architecture: A Quantitative Approach'', John L. Hennessy & David A. Patterson | |||
* ''[http://www.eecs.berkeley.edu/~culler/courses/cs252-s05/lectures/cs252s05-lec06-scoreboard.ppt EECS 252 Graduate Computer Architecture Lec XX - TOPIC]'', Electrical Engineering and Computer Sciences, Berkeley, University of California. | |||
[[Category:Instruction processing]] |
Revision as of 23:32, 20 January 2014
Scoreboarding is a centralized method, used in the CDC 6600 computer, for dynamically scheduling a pipeline so that the instructions can execute out of order when there are no conflicts and the hardware is available.[1] In a scoreboard, the data dependencies of every instruction are logged. Instructions are released only when the scoreboard determines that there are no conflicts with previously issued and incomplete instructions. If an instruction is stalled because it is unsafe to continue, the scoreboard monitors the flow of executing instructions until all dependencies have been resolved before the stalled instruction is issued.
Stages
Instructions are decoded in order and go through the following four stages.
- Issue: The system checks which registers will be read and written by this instruction. This information is remembered as it will be needed in the following stages. In order to avoid output dependencies (WAW - Write after Write) the instruction is stalled until instructions intending to write to the same register are completed. The instruction is also stalled when required functional units are currently busy.
- Read operands: After an instruction has been issued and correctly allocated to the required hardware module, the instruction waits until all operands become available. This procedure resolves read dependencies (RAW - Read after Write) because registers which are intended to be written by another instruction are not considered available until they are actually written.
- Execution: When all operands have been fetched, the functional unit starts its execution. After the result is ready, the scoreboard is notified.
- Write Result: In this stage the result is about to be written to its destination register. However, this operation is delayed until earlier instructions—which intend to read registers this instruction wants to write to—have completed their read operands stage. This way, so called data dependencies (WAR - Write after Read) can be addressed.
Data structure
To control the execution of the instructions, the scoreboard maintains three status tables:
- Instruction Status: Indicates, for each instruction being executed, which of the four stages it is in.
- Functional Unit Status: Indicates the state of each functional unit. Each function unit maintains 9 fields in the table:
- Busy: Indicates whether the unit is being used or not
- Op: Operation to perform in the unit (e.g. MUL, DIV or MOD)
- Fi: Destination register
- Fj,Fk: Source-register numbers
- Qj,Qk: Functional units that will produce the source registers Fj, Fk
- Rj,Rk: Flags that indicates when Fj, Fk are ready
- Register Status: Indicates, for each register, which function unit will write results into it.
The algorithm
The detailed algorithm for the scoreboard control is described below:
function issue(op, dst, src1, src2)
wait until (!Busy[FU] AND !Result[dst]); // FU can be any functional unit that can execute operation op
Busy[FU] ← Yes;
Op[FU] ← op;
Fi[FU] ← dst;
Fj[FU] ← src1;
Fk[FU] ← src2;
Qj[FU] ← Result[src1];
Qk[FU] ← Result[src2];
Rj[FU] ← not Qj;
Rk[FU] ← not Qk;
Result[dst] ← FU;
function read_operands(FU)
wait until (Rj[FU] AND Rk[FU]);
Rj[FU] ← No;
Rk[FU] ← No;
function execute(FU)
// Execute whatever FU must do
function write_back(FU)
wait until (f {(Fj[f]≠Fi[FU] OR Rj[f]=No) AND (Fk[f]≠Fi[FU] OR Rk[f]=No)})
foreach f do
if Qj[f]=FU then Rj[f] ← Yes;
if Qk[f]=FU then Rk[f] ← Yes;
Result[Fi[FU]] ← 0;
Busy[FU] ← No;
Remarks
The scoreboarding method must stall the issue stage when there is no functional unit available. In this case, future instructions that could potentially be executed will wait until the structural hazard is resolved. Some other techniques like Tomasulo algorithm can avoid the structural hazard and also resolve WAR and WAW dependencies with Register renaming.
See also
References
43 year old Petroleum Engineer Harry from Deep River, usually spends time with hobbies and interests like renting movies, property developers in singapore new condominium and vehicle racing. Constantly enjoys going to destinations like Camino Real de Tierra Adentro.
External links
- Dynamic Scheduling - Scoreboard
- Computer Architecture: A Quantitative Approach, John L. Hennessy & David A. Patterson
- EECS 252 Graduate Computer Architecture Lec XX - TOPIC, Electrical Engineering and Computer Sciences, Berkeley, University of California.
- ↑ 55 years old Systems Administrator Antony from Clarence Creek, really loves learning, PC Software and aerobics. Likes to travel and was inspired after making a journey to Historic Ensemble of the Potala Palace.
You can view that web-site... ccleaner free download