Statical ILP

VLIW & EPIC

compile time에 패럴리즘을 넣어봅시다
- 런타임에 패럴리즘 하는 건 비싸거든요
- 그리고 만들기 어렵기도 하고, 스케쥴링 로직에 의해서도 제한이 있음.
- Scheduling Complexity 도 O(R^2)로 비싸요
VLIW의 특징들
- cycles == instructions
- latency dependent
- Area와 Timing 에서 이득
- 단점: Binary incompatibility, code bloating

다시 컴파일하는 것도 문제고, 컴파일 할 수 있는 것도 문제
그렇다고 컴파일을 안 하면, CPU 변경 자체가 불가...
- cycle 수를 바꾸고 싶을 수도 있고
  - latency를 늘려서 inst의 크기를 잘 잘라보고 싶은데
  - 줄이는 것도 dependency때문에 이상해짐
- 아니면 구조 자체를 바꾸고 싶을 수도

보통 생으로 컴파일하면 패럴리즘 보기 힘듦
- 그래서 잘 노력해야함
- 근데 dependency가 문제
컨트롤 디펜던시
- 예상해서 움직이자.
- Predicate 넣어서 일단 미리 계산하고 반영
Loop Transformation
- Loop peeling
- Loop Fusion
- Loop Distribution
- Loop Unrolling
- SW Pipelining
  - 루프 안 잘 배열하면 병렬로 돌릴 수 있음
  - 언롤링해서 잘 봅시다
루프 언롤 등으로 code bloating 다시 생김
Nonloop control dependency
- 대강 브랜치 결과가 예상이 된다면 유력한 블록을 최대한 줄여보자
  - 틀렸을 때 recover하는 비용이 들지만, 그것보다 유력한 블록 안의 요소들을 파이프라이닝 할 수 있다는 게 장점
- Trace scheduling
Dynamic ILP 와 speculation 비교
- Where? Predictors vs nothing
- nullify? Reorder buffer vs nothing (due to the register renaming)
- exceptions? ROB vs Poisoned bit
repeat Generate region, schedule, generate compensation code
- 최적화 더 못할 때까지
슈퍼블록 스케쥴링 - 더 큰 단위로 스케쥴링
WAW, WAR 은 레지스터 리네이밍으로 없앰
RAW 가 문제.
- 근데 가장 중요한 점은 RAW가 확실히 생길지 아니면 안 생길지 알 수가 없어요
- 그래도 고민할 시간은 많으니 조금 더 고민
어쨌든 어려움

그래서 나온 방법
JIT 같은 느낌
Emulation 과 Translation을 섞어 쓰자
- Emulation : 쉽지만 느림
- Translation : 빠르지만 어렵고 구현안되는 것들이 있음
처음에는 Emulation 으로 시작해서 자주 쓰고 성능이 필요한 부분 translate
OS와 Machine 사이의 Layer 추가
최적화
- cache 활용
Exception에서 문제
- Synchronous한 경우인데 Translation까지 했다? 정확하게 recover 어려움
- revert 하고 emulate 하는 방법. Arch Support 있어야 함
  - Shadow reg, store buffer 활용
Benefits
- Compatibility
- Reliability and possiblity to upgrade
- Low HW cost
- High ILP
- Low Power
Cons
- reduced resources
- 시작이 느림 (에뮬레이션으로 시작하니)
- 기계어와 사용자 코드가 너무 달라 디버깅이 어려움