파이프 라인 구조 <Pipelined Structure>

파이프라인(pipeline) 처리는 작업 처리 과정을 여러 개의 작은 작업으로 나누고 각각을 시간적

으로 중첩되게 처리하는 것이다. 예를 들어 어떤 작업을 A,B,C 세 단계로 나누고 이것을 세 번

반복해서 처리한다고 생각해 보자.

CPU의 명령어 처리 능력 향상 기법

- CPU의 높은 Clock Frequency

- 병렬처리 / 병렬 구조 ( Parallelism process / Parallel Structure )

 멀티 프로세서 구조 , 파이프 라인 구조

작업처리 시간 = 실행 명령어 수 * CPI * 클록주기

( Job Processing time = Executive Instruction * CPI * Clock Cycle )

CPU의 작업 실행에는 두가지 방법이 있다.

a) 순차적 실행

A | B | A | B | A | B | A | B | A | B | A | B | A | B | 

b) 파이프 라인 실행

A | A | A | A | A | A |

     B | B | B | B | B | B |

< 파이프 라인 프로세서 > - 시간적 병렬 처리

순처적이고 연속적인 작업을 여러 개의 서브 프로세서 ( Sub Processor )  로 분해하고, 각가의

서브프로세서(sub Processor)들은 모든 다른 세그먼트(segment)들과 동시에 실행되는 특정한

세그먼트 ( Segment ) 내에서 수행되도록 하는 기법을 파이프 라이닝 이라 하고 , 이때 세그먼트

(segment) 또는 단계(stage)라고 서브프로세서를 기능별로 나눈다.

< 파이프라인 구조의 처리과정 >

각 명령어의 실행시간은 같으나 명령어 처리율은 증가

명령어 패치 -> 디코딩 및 유효주소 계산 -> 오퍼랜드 패치 -> 실행

Instruction Fetch -> Instruction Decoding -> Operand Fetch -> Executive

단계1 : 메모리 (캐쉬)로부터 명령어 패치 (fetch) ( Instruction Fech )

단계2 : 명령어의 명령모드를 디코드하고 , 오퍼랜드의 유효주소 계산 ( ID )

단계3 : 메모리 (캐쉬)로부터 오퍼랜드 패치 ( Fetch ) ( OF )

단게4 : 명령 코드의 내용을 실행 ( EX )

< 파이프라인 Speedup >

CPU의 성능을 개선하기 위해서 CPU를 파이프라인 구조로 설계할 때에는 다음 사항을 고려해야 한다.

- 명령어는 동일한 처리 과정을 갖는다.

 : 모든 명령어가 동일한 처리 과정을 갖지 않으면 가장 긴 처리 단계를 갖는 명령어에 대하여

   파이프라인 구조를 구현해야 한다. 처리 단계가 짧은 명령어는 가장 긴 처리 단계의 파이프라인

  구조에 의해 처리 시간이 지연된다. 이러한 문제를 해결하기 위해 가능한 모든 명령어가 동일한

  처리 과정을 갖도록 명령 코드와 주소지정 모드를 설계 한다.

- 각 단계의 처리 시간은 동일해야 한다.

 : 파이프라인의 각 단계별 처리 시간이 일정하지 않으면, 예를 들어 단계 1,2,4의 처리 시간은

   1 클럭 주기이고, 단계 3의 처리 시간은 2 클럭 주기이라고 하면 가장 긴 처리 시간인 2클럭

   주기가 파이프라인 주기가 된다.

  명령어 페치 시간은 메모리 접근 시간에 의해서 정해지며 페치 과정이 1사이클내에 이루어 지

  려면 명령어를 저장하는 메모리가 CPU내에 있어야 한다. 따라서 CPU내에 위치 하는 온 칩

  캐시는 파이프라인 구조에서 필수적이다.

  메모리 참조가 한 사이클 내에 처리되더라도 명령 코드의 실행 단계에서 긴 연산이 요구되는

  실행은 별도의 프로세서에서 실행할 수 있도록 하고 한 사이클 내에 실행 가능한 경우만 명령

  코드로 정의하는 것이 효율적이다.

- 명령어는 순차적으로 실행한다.

그러나 분기 명령어 함수 호출 반환 명령어 등은 순차적으로 실행되지 않는다. 따라서 순차적으로

실행되지 않는 이러한 명령어들을 파이프라인으로 처리하면 지연이 발생하게 되어 파이프라인의

성능을 감소시킨다.

무조건 분기 명령의 경우는 명령어 인출 또는 해독 시에 미리 명령어의 유형(분기 여부의 결정)을

판별하여 목적지의 명령어를 미리 인출 할 수 있다.

조건부분기 명령에 대해서는 분기 예측 방법에 의해서 분기가 발생할 지를 미리 예측하여 예측된

목적지의 명령어를 미리 인출한다.

- 명령어의 상호 의존성이 없어야 한다.

그러나 실제 프로그램의 실행 시에는 명령어들 사이에 데이터 및 주소의 의존성이 있을때는

파이프라인에서 실행 지연이 발생한다. 따라서 명령어 사이의 데이터 및 주소 의존성이 없도록

번역시 고려하여야 한다. 다음과 같은 명령어들은 데이터 및 주소의 의존성이 있다.

ADD R1, R2

MOV R3, R1

MOV R4, (R3)

앞의 명령들이 파이프라인에서 실행될 때 R1은 첫번째 명령어의 수행 결과 이면서 두번째 명령

의 오퍼랜드이므로 데어터의 의존성이 있다.

또 세번째 명령어의 두번째 오퍼랜드는 레지스터 간접 주소로 지정되고 유효주소인 R3의 값은

두번째 명령어의 결과이므로 주소의 의존성이 있다.

- 공유 자원에서 충돌이 없어야한다.

동일한 사이클 내에 파이프 라인의 여러 단계 에서 동일한 자원을 사용하려 한다면 출돌이 발생하

여 처리에 지연이 발생한다. 예를 들어, 명령어 인출(Instruction Fetch)은 매 사이클마다 발생하

는 데 같은 사이클에서 메모리에 저장된 오퍼랜드를 동시에 인출하면 공유 자원인 메모리에서 충돌

이 발생한다. 이러한 문제는 별 개의 온칩 명령어 캐시와 온칩 데이터 캐시를 사용하면 해결할

 수 있다.

< 파이프 라인 CPU 분석 >

1) 처리 과정이 동일하지 않은 명령어의 실행 ( CISC 적 구조 )

문제점 :  가장 긴 처리 단계를 갖는 명령어로 동작

        -> 모든 명령어의 처리 과정이 같도록 명령어 집합 ( RISC 적 명령어 집합 )

        설계 예 ) Load , Store 명령어 만 메모리 접근 허용

2) 일정하지 않은 각 단계 별 처리 시간

문제점 : 가장 긴 처리 간계 시간이 파이프라인의 시이클 주기

            수행이 완료된 단계의 결과는 래치 ( Latch ) 에 저장

        -> 각 단계별 처리 시간이 같도록 구조 설계

            온칩 캐쉬 , 코프로세서

3) 분기 명령어의 영향

(1) 무조건부 분기 의 처리

   -> 명령어 패치 또는 디코딩시에 분기를 미리 판별

(2) 조건부 분기의 처리

 - 지연 분기 ( Delayed branch)의 활용

    : 제안 :  분기 명령어와 앞에 위치한 다른 명령어의 순서를 바꾸어서 실행

 - 분기 예측 기법

   정적 예측 기법 : 컴파일 시에 분기를 미리예측

   동적 예측 기법 : 실행 도중에 발생된 자료를 분기 예측에 활용

                          이전에 발생한 분기의 기록을 활용

                         -> 2 path fetch : 2개의 파이프라인 구조 운영

                                              분기 목적 주소의 명령어를 별도의 파이프라인을 통해 페치

4) 명령어 사이의 의존성

   -> 결과를 직접 두 번째 명령어의 오퍼랜드에 전송하는 기법 ( Operand Forwarding )

5) 자원의 부족에 의한 충돌

   -> 명령어 페치와 오퍼랜드 페치가 동시에 실행되도록 설계 별개의 온칩 명령어 캐시와

        온칩 데이터 캐시  활용..

미룸클리닉 딸기 style 아이베제 토이앤기프트 그분이 생각날땐 극심한 이기주의자 기다림 아침안개 데님파티 행복가득우리집