위험(컴퓨터 아키텍처)
Hazard (computer architecture) |
중앙처리장치(CPU) 설계 영역에서는 다음 명령을 다음 클럭 [1]사이클에서 실행할 수 없을 때 CPU 마이크로아키텍처의 명령 파이프라인에 문제가 발생하여 계산 결과가 잘못될 수 있습니다.일반적인 위험의 세 가지 유형은 데이터 위험, 구조적 위험 및 제어 위험(분기 위험)[2]이다.
파이프라인 스톨/파이프라인 버블링, 오퍼랜드 포워딩, 순서가 어긋난 실행의 경우 스코어보드 방법 및 Tomasulo 알고리즘 등 위험 처리에 사용되는 여러 가지 방법이 있습니다.
배경
파이프라인 프로세서의 명령어는 여러 단계로 실행되므로 항상 여러 명령이 fetch 및 execute와 같은 파이프라인의 다양한 단계에서 처리됩니다.명령 파이프라인 마이크로아키텍처는 여러 가지가 있으며 명령어가 순서대로 실행되지 않을 수 있습니다.이러한 동시(오품일 가능성이 있는) 명령 중 두 개 이상이 충돌할 경우 위험이 발생합니다.
종류들
데이터 위험
데이터 위험은 데이터 의존성을 나타내는 명령이 파이프라인의 여러 단계에서 데이터를 수정할 때 발생합니다.잠재적 데이터 위험을 무시하면 경주 조건(경주 위험이라고도 함)이 발생할 수 있습니다.데이터 위험이 발생할 수 있는 상황은 다음 3가지입니다.
- 진정한 의존관계인 쓰기 후 읽기(RAW)
- 읽기 후 쓰기(WAR), 반의존성
- 출력 의존 관계인 쓰기 후 쓰기(WAW)
판독 후 판독(RAR)은 위험 요소가 아닙니다.
두 가지 지침을 고려합니다.i1과 i2는 프로그램 순서상 i2보다 i1이 먼저 발생합니다.
쓰기 후 읽기(RAW)
(i2는 i1이 쓰기 전에 소스를 읽으려고 한다) RAW(Read After Write) 데이터 위험이란 명령이 아직 계산되거나 검색되지 않은 결과를 참조하는 상황을 말한다.이 문제는 이전 명령이 실행된 후 명령이 실행되더라도 이전 명령이 파이프라인을 통해 일부만 처리되었기 때문에 발생할 수 있습니다.
예
예를 들어 다음과 같습니다.
i1. R2 <- R5 + R3 i2R4 <- R2 + R3
첫 번째 명령은 레지스터 R2에 저장되는 값을 계산하는 것이며 두 번째 명령은 이 값을 사용하여 레지스터 R4의 결과를 계산합니다.단, 파이프라인에서는 피연산자가 제2연산을 위해 페치되었을 때 제1연산자의 결과가 아직 저장되지 않아 데이터 의존성이 발생한다.
데이터 의존성은 명령 i1의 완료에 의존하므로 명령 i2에서 발생한다.
읽기 후 쓰기(WAR)
(i2는 i1이 읽기 전에 수신처를 쓰려고 한다) WAR 데이터 리스크는 동시 실행의 문제를 나타낸다.
예
예를 들어 다음과 같습니다.
i1. R4 <- R1 + R5 i2 。R5 <- R1 + R2
i2가 i1보다 먼저 종료할 가능성이 있는 상황(즉, 동시 실행)에서는 i1이 오퍼랜드를 취득할 기회가 있기 전에 레지스터 R5의 결과가 저장되지 않도록 해야 한다.
쓰기 후 쓰기(WAW)
(i2는 i1이 쓰기 전에 오퍼랜드를 쓰려고 한다) WAW(Write after Write) 데이터의 위험이 동시 실행 환경에서 발생할 수 있다.
예
예를 들어 다음과 같습니다.
i1. R2 <- R4 + R7 i2R2 <- R1 + R3
i2의 라이트백(WB)은 i1의 실행이 완료될 때까지 지연되어야 합니다.
구조적 위험
이미 파이프라인에 있는 두 개 이상의 명령이 동일한 리소스를 필요로 하는 경우 구조적 위험이 발생합니다.그 결과 명령어는 파이프라인의 일부에 대해 병렬이 아닌 직렬로 실행되어야 합니다.구조적 위험은 자원 위험이라고도 한다.
예:여러 명령이 실행 명령 단계로 진입할 준비가 되어 있고 단일 ALU(산술 로직 유닛)가 존재하는 상황입니다.이러한 자원 위험에 대한 해결책 중 하나는 메인 메모리에 여러 포트를 설치하고 여러 개의 ALU(산술 논리 유닛) 장치를 사용하는 등 사용 가능한 자원을 늘리는 것입니다.
제어 위험(지점 위험 또는 지시 위험)
제어 위험은 파이프라인이 분기 예측에 대한 잘못된 결정을 내리고 이후 폐기해야 하는 명령을 파이프라인에 가져올 때 발생합니다.분기 위험이라는 용어는 제어 위험을 의미하기도 합니다.
위험 요소 제거
포괄적인
파이프라인 버블링
파이프라인의 버블링은 파이프라인 파손 또는 파이프라인 정지라고도 불리며 데이터, 구조 및 분기 위험을 배제하는 방법입니다.명령을 가져올 때 제어 논리에 따라 위험이 발생할 수 있는지 여부가 결정됩니다.이것이 참일 경우 제어 로직은 파이프라인에 작업(NOP)을 삽입하지 않습니다.따라서 다음 지침(위험의 원인이 될 수 있음)이 실행되기 전에 이전 지침은 위험을 완료하고 예방하기에 충분한 시간이 있었다.NOP의 수가 파이프라인의 단계 수와 같을 경우 프로세서는 모든 명령을 지우고 위험에서 벗어날 수 있습니다.모든 형태의 스톨은 프로세서가 실행을 재개하기 전에 지연을 발생시킵니다.
분기 명령이 새 메모리 위치로 이동하면 파이프라인 플러시가 발생하여 파이프라인의 모든 이전 단계가 비활성화됩니다.이러한 이전 단계는 클리어되어 [3][4]브런치가 나타내는 새로운 명령으로 파이프라인이 속행할 수 있습니다.
데이터 위험
데이터 위험을 해결하기 위해 사용되는 몇 가지 주요 솔루션과 알고리즘이 있습니다.
- RAW(Read After Write) 의존 관계가 발생할 때마다 파이프라인 버블을 삽입하여 지연 시간을 늘립니다.
- 파이프라인 버블을 방지하기 위해 순서가 잘못된 실행을 사용한다.
- 피연산자 전달을 사용하여 파이프라인의 이후 단계의 데이터를 사용합니다.
순서가 잘못된 실행의 경우 사용되는 알고리즘은 다음과 같습니다.
데이터 의존성을 제거하는 작업은 컴파일러에 위임할 수 있습니다.컴파일러는 의존 명령 간에 적절한 수의 NOP 명령을 입력하여 올바른 동작을 보장하거나 가능한 경우 명령 순서를 변경할 수 있습니다.
오퍼랜드 전송
예
- 다음 예제에서는 계산된 값은 굵은 글씨로 표시된 반면 레지스터 번호는 굵은 글씨로 표시되지 않습니다.
예를 들어, 값 3을 레지스터 1(이미 6을 포함)에 쓴 다음 레지스터 1에 7을 더하고 결과를 레지스터 2에 저장하려면 다음과 같이 하십시오.
i0: R1 = 6 i1: R1 = 3 i2: R2 = R1 + 7 = 10
실행 후 레지스터 2는 값 10을 포함해야 합니다.단, i2가 실행되기 전에 i1(레지스터 1에 쓰기 3)이 파이프라인을 완전히 종료하지 않으면 i2가 덧셈을 실행할 때 R1은 값 3을 포함하지 않는다는 것을 의미합니다.이 경우 i2는 레지스터 1(6)의 오래된 값에 7을 더하기 때문에 레지스터 2는 대신 13을 포함한다.
i0: R1 = 6 i2: R2 = R1 + 7 = 13 i1: R1 = 3
이 오류는 i1이 레지스터 1에 쓰기 작업 결과를 커밋/저장하기 전에 i2가 레지스터 1을 읽기 때문에 발생합니다.따라서 i2가 Register 1의 내용을 읽을 때 Register 1에는 3이 아닌 6이 포함됩니다.
전송(아래 설명)은 값 3이 레지스터 1에 커밋/저장되기 전에 후속 명령에 의해 i1(3)의 출력을 사용할 수 있다는 사실에 따라 이러한 오류를 수정하는 데 도움이 됩니다.
이 예에 적용되는 전송은 후속 명령(이 예에서는 i2)에서 i1의 출력을 사용할 수 있도록 하기 전에 레지스터 1(이 예에서는 출력 3)에 커밋 또는 저장하기 위해 대기할 필요가 없음을 의미합니다.그 결과 i2는 올바른(더 최근의) 레지스터 1의 값을 사용합니다.커밋/스토어는 파이프라인 없이 즉시 이루어졌습니다.
전달을 활성화하면 파이프라인의 명령 디코드/실행(ID/EX) 단계에는 지정된 레지스터에서 읽은 값(이 예에서는 레지스터 1의 값 6)과 다음 단계 명령 실행/메모리 액세스(EX/MEM)에서 전송되는 레지스터 1의 새 값(이 예에서는 3)의 두 가지 입력이 있습니다.추가되었습니다.제어 로직은 사용할 입력을 결정하는 데 사용됩니다.
관리 위험(지점 위험)
제어 위험을 피하기 위해 마이크로아키텍처는 다음을 수행합니다.
- 파이프라인 버블 삽입(상기 참조), 지연 시간을 늘립니다.
- 분기 예측을 사용하여 기본적으로 어떤 명령을 삽입할지에 대해 교육을 받은 추측을 한다. 이 경우 파이프라인 버블은 예측이 올바르지 않은 경우에만 필요하다.
잘못된 명령어가 파이프라인에 들어간 후 분기가 파이프라인 버블을 일으키는 경우, 잘못 로드된 명령어가 잘못 로드된 것으로 판명되기 전에 프로세서 상태에 에너지 낭비 처리를 제외한 모든 명령어가 영향을 미치지 않도록 주의해야 합니다.
기타 기술
메모리 레이텐시는 설계자가 주의해야 할 또 다른 요소입니다.지연으로 인해 퍼포먼스가 저하될 수 있기 때문입니다.메모리의 종류에 따라, 메모리에의 액세스 시간이 다릅니다.따라서 설계자는 적절한 메모리 유형을 선택함으로써 파이프라인 [5]데이터 경로의 성능을 향상시킬 수 있습니다.
「 」를 참조해 주세요.
레퍼런스
- ^ 패터슨 & 헤네시 2009, 335페이지
- ^ 패터슨 & 헤네시 2009, 335-343페이지.
- ^ "Branch Prediction Schemes". cs.iastate.edu. 2001-04-06. Retrieved 2014-07-19.
- ^ "Data and Control Hazards". classes.soe.ucsc.edu. 2004-02-23. Retrieved 2014-07-19.
- ^ Cheng, Ching-Hwa (2012-12-27). "Design Example of Useful Memory Latency for Developing a Hazard Preventive Pipeline High-Performance Embedded-Microprocessor". VLSI Design. 2013: 1–10. doi:10.1155/2013/425105.
일반
- Patterson, David; Hennessy, John (2009). Computer Organization and Design (4th ed.). Morgan Kaufmann. ISBN 978-0-12-374493-7.
- Patterson, David; Hennessy, John (2011). Computer Architecture: A Quantitative Approach (5th ed.). Morgan Kaufmann. ISBN 978-0-12-383872-8.
- Shen, John P.; Lipasti, Mikko H. (2013) [2004]. "2.2.3.2 Identication of Pipeline Hazards". Modern Processor Design: Fundamentals of Superscalar Processors. pp. 73–78. ISBN 9781478610762.
외부 링크
- "Automatic Pipelining from Transactional Datapath Specifications" (PDF). Retrieved 23 July 2014.
- Tulsen, Dean (18 January 2005). "Pipeline hazards" (PDF).
