오래 못 할 짓 하지 않기

구성 요소 ● Machine Instruction 1. 프로세서의 언어 2. 어떤 연산을 수행할지 알려줌. + 프로그램 : 정해진 일을 수행하는 명령어의 순서 레지스터 1. CPU에 있음 2. 임시 [ 명령어/데이터 ] 저장소 3. Main Memory보다 빠르지만 비싸다. 빠른 이유: CPU에 있으니까 정보 가져오기 훨씬 가깝다. 4. 종류 1) 일반적인 목적 = 계산하는 용도 ex) r0, r1 2) 특수한 목적 = PC(program Counter) : 다음에 수행할 명령어의 주소를 갖고있다. CPU에 있는 Register AC(Accumulator) : 명령어에 대한 결과를 잠시 갖고있는다. - 아래 사진에서 오른쪽 사진에 있는 register가 AC임. ( sum = sum+ i 인 반복문 ) ..

Flushing logic 이 필요한 이유 : Control Hazard가 발생했을 때, = (Branch 명령어 O 이고 조건도 되었을 때, 조건이 되기까지 같이 실행되고 있었던 애들이 날아가는 거 ) → 아래 사진으로 보면, 40번 명령어 beq가 4번째 CLK일 때 Branch가 되는 건데, 4번째 CLK이 될 때까지 실행된 and, or, add 명령어는 flush 되고 72번 명령어가 실행되어야 한다. 따라서 Branch 가 일어났을 때 , 실행했던 몇 개의 명령어가 날아가는 손실을 막기 위해 [ Branch Optimization ]을 한다. 이는 Branch를 하는지 하지 않는지 판단하는 게 EX 와 MEM stage에 있는데 이걸 ID stage로 옮기는 것이다. 그럼 손실은 IF단에 있는..

▣ Data Fowarding 이 필요할 때 : Data hazard가 발생했을 때 = Register Data들끼리 Dependency 가 있을 때임 → Register file에 Write는 CLK의 앞부분 , Read는 뒷부분에서 일어나서 같은 Stage에 겹치더라도 ㄱㅊㄱㅊ 때문에 Dependecy가 있는 파일을 쓰고, 그 다음 명령어에서 읽는 것이 [ 같은 Stage일 때 ] 는 Hazard가 발생 X 하지만, 그 이상일 때는 어떻게 할 것인가? ☞ Data Forwarding R-Type 연산의 결과는 5번째 CLK에서 " 저장 " 되지만 저장이 아닌 연산이 실행되고 끝나는 것은 3번째 CLK에서 끝난다. ▣ 따라서, 이 정보를 가져와서 Dependency로 인한 hazard를 없애기 위해서는..

Control Hazard 해결법 Stall → 문제가 해결될 때까지 실행 중지 Optimized branch processing → 손실을 최소화하는 방법 → Branch 에서 Hazard가 발생하면 3CLK을 낭비하게 됨. → 3CLK 손실을 1CLK으로 바꿈 Branch Predicition → Branch 가 될 지될지 안 될지 먼저 예측하여, Branch 될 데이터만 가져오기 Delayed branch → NOP로 순서를 늦추기. - 1번은 Data Hazard에서 다루었음 - Optimized Branch Processing 필요한 정보 1) Branch 가 일어나는지 안 일어나는지 " 미리 " 알아야 한다. 2) Target address를 " 미리 " 계산해두어야 한다. → Branch E..

Data Hazard 발생 조건 : 이전 명령어와 현재 명령어의 Dependency가 있을 때 → 이전 명령어의 결과가 구해져야 현재 명령어를 실행할 수 있기 때문에 Hazard 해결법 : 뒤에 따라오는 명령어의 실행을 늦춘다. = Stall Stall 구현법 : Freezing the pipeline (Internal) Forwarding Compiler scheduling ▣ Freezing The Pipeline ADD 와 SUB을 먼저 보면 ADD $( Rd = 저장될 곳 ) , $( Rs = Operand 1 ) , $ ( Rt = Operand 2 ) 이다. 결괏값을 $1에 저장한다. SUB 에서는 $1 과 $5 의 연산의 결괏값을 $4에 저장한다. 근데 SUB가 Register file에서 ..

Pipeline Control 고려할 점 : 이전까지의 Control들은 현재 돌아가고 있는 명령어가 하나밖에 없었기 때문에 그냥 제어하면 되었는데 Pipeline에서는 여러 명령어가 돌고 있을 수 있다. 1) 같은 명령어라도 몇 번째 CLK Cycle인지 2) 동시에 5개의 명령어에 대한 Control이 필요함. 각 Stages ( steps ) 에서 Control 되어야 하는 것 IF : 딱히 control 할 거 없음 ID : 딱히 control 할 거 없음 EX : 명령어에 따라 RegDst , ALUOp , ALUSrc MEM : 명령어에 따라 Branch, MemRead, MemWrite WB : 명령어에 따라 MemtoReg , RegWrite 그럼 어떻게 알맞게 우리가 Control 신호를..

Pipeline DataPath Pipeline에 Hazards가 없다고 가정하고 Datapath를 설계할 예정이다. 정확히 Pipeline의 모양은 이렇다. 돌림노래라고 생각하면 가장 이해하기 쉬울 듯. 5번째 CLK일 때(부터), 5개의 명령어가 Pipeline 꽉꽉 채워서 다 돌아감 Single Cycle Datapath를 Pipeline 5 steps에 맞춰 나누었음. IF = PC , Instruction memory 를 이용하여 instruction을 가져온다. ID = Register file 를 읽는다. EX = ALU 로 연산을 한다. MEM = Memory 에 access한다. WB = Memory 혹은 ALU에서 나온 값을 받아서 Register file로 back한다. 중요한 점은,..

Basic Steps of Execution of Pipeline Instruction Fetch (IF) Instruction decode / Register Fetch (ID) Execution / Effective address (EX) Memory access (MEM) Register write-back (WB) Multiple에서 : 위 작업을 하는 데 걸리는 시간이 [ 5 CLK * 개수 ] 였음 Pipeline에서 : 첫 번째 수행하는 놈이 1번을 끝내고 2번으로 갔다 → 두 번째 놈이 1번으로 들어감 (돌림노래 한다고 생각하면 됨) 위 실행은 Pipeline이 X일 때의 모습이고 아래 실행은 Pipeline으로 실행했을 때의 모습이다. +ADD인 경우에 3단계로 끝나기 때문에 4단계가 딱..

Pipeline 목적 : CPU의 기능을 향상시키기 여러 개의 명령어를 한 번에 함으로써 기능을 향상시킴. 예시) 세탁실에 세탁기와 건조기가 1개씩 있다고 생각해 보자. 세탁기와 건조기 1개당 돌리는데 각각 1시간이 걸린다. Case 1) 이 상황에서 부대에 SIP가 걸렸다. 동선이 절대 겹치면 안 됨. 그럼 한 사람이 세탁기와 건조기를 다 돌려서 2시간이 지난 뒤에야 다른 사람이 들어와서 새로 세탁을 시작할 수 있다. 이랬을 때 4명이 세탁과 건조를 다 끝냈을 땐 8시간이 지나있음. Case 2) SIP가 풀렸다. 한 사람이 세탁을 끝나고 건조기에 넣을 때, 그다음 사람이 세탁기에 세탁물을 넣을 수 있다. 이렇게 되었을 때 4 사람이 세탁 건조를 다 끝냈을 때는 아래 그림과 같이 5시간이 지나있다. C..

Multiple Cycle Control Unit 사진에 보이는 주황색 원이 Control Unit이다. Single Cycle 에서 다루었듯이 이건 Finite state machine이다. (상태로 제어함) 이걸 보고 R타입일 땐 어떤 게 0,1 (Or 2,3까지) 켜지는지 할 줄 알아야 한다. 이전 시간에 배웠던 걸 가져와서 Finite state 로 표현해 보자 초기 상태 = S0 (fetch 할 예정) S1 에서 R타입이다 = 가장 위 S1 에서 I타입이다 = 가운데 S1 에서 Branch타입이다 =가장 아래 이런 식으로 표현 가능하다. 예제 풀어보기 (9:41) Single clock cycle ↔ Multi clock cycle 비교 조건 1. LW inst 10번 실행 + SW inst 1..