**Fetch & Decode to uop                Execution units
				                    (superscalar 4way)
+----+     +---+---core0--+        +--------+     +------------+       +-------+
|DRAM| sys |L3 | L2 | L1-I|------> |re-order| -/> |Reservation | -uop> |mul,div|
|    | bus |   |    | L1-D|   |--> |buffer  |     |station.    |       +-------+
|    | --> |   |    | + BH|   |--> |        |     |            | -uop> |add,sub|
|    |     |   |    |     |   |--> |        |     |            |       +-------+
|    |     |   |---core1--|        +--------+     | - - - - - -| -uop> |store. |
+----+     +---+----------+             |         |  Register  |       +-------+
											                  |         +------------+ -uop> |load.  |
                                        |                |             +-------+
                                        |                |               | |
                                        +----------------+---------------+ |
                                                 Internal data bus         |
                                                                       +-------+
                                                                       |L1-DATA|
 (by hyunjunk)                                                         +-------+**

system bus → 메모리 컨트롤러나 DMA 컨트롤러가 캐시까지 프로그램을 가져옴

L1-cache → non-temporal 같은 캐시를 거치지 않는 특수한 상황이 아니라면, 기본적으로 모든 데이터와 코드는 연산되기 전에 L3-L2을 거쳐 L1까지 fetch 되어야 함. instruction과 data를 동시에 fetch하기 위해 I-cache와 D-cache로 나뉨 + Branch History도 여기에 저장

fetch → 캐시에서 cpu 버퍼로 읽어옴

superscalar → 이 때, 하나씩 fetch 하면 느리므로 n개씩 한꺼번에 읽어들임 (만약 branch prediction이 실패해서 파이프라인을 flush하면 빠르게 명령어들을 다시 채울 수 있어야 함). +(뒤의 파이프라인 과정도 여러개씩 한꺼번에 진행하는데, skylake architecture를 보면 책에서 나오는 것 처럼 단계별로 슈퍼스칼라 개수가 n개씩 고정인게 아니라 멋대로임)

decode → 명령어를 해독함. cisc 명령어는 길이가 가변적이라 복잡.
risc의 고정길이 명령어셋 인 경우 간단하여 fetch-decode를 한 번에 진행하기도 함.

• cisc 명령어는 복잡해서 pipelining 하기 힘듬(한 명령어가 execution stage를 점유하는 시간이 김). 그래서 작은 단위인 uop(micro operation)으로 변환

re-order buffer → out-of-order 프로세서에서 필요한 버퍼. 의존성 등을 보고 re-order 시킴. 이 때 rename도 진행 (가짜의존성 제거)

reservation station → uop들이 의존성이 없어지거나 execution unit이 not busy 할 때 까지 대기.

execution units → 실행 유닛. 각 실행 유닛 별로 기능을 분리해서, 병렬적으로 돌릴 수 있도록 함(설계마다 다른 듯)

internal data bus → 레지스터 값 load나 레지스터에 store를 지원.

execution 까지 끝나면 → writeback + forward-operand로 대기중인 다른 uop을 깨우고 기다리던 결과를 가져다주거나, commit하여 실행결과를 확정(레지스터나 캐시에 저장) commit이 존재하는 이유는 page protection 등을 검사하고 결과를 취소할 수 있어야 하기 때문.

더 자세한 다이어그램은 여기

full overview of the Intel Skylake microarchitecture.

중간에 load buffer나 saves buffer 같은 것들이 있는데 이게 뭐 하는지 잘 모르겠음. 내 생각에는 투기적 실행을 하고 실패 시 rollback 하려고 버퍼를 따로 두는 듯 ?

Line Fill Buffer는 WC buffer임 이름이 바뀐 듯