도 1 의 예시 에서 , FTQ ( 130 ) 의 각 엔트리 에 는 예컨대 기본 블록 의 시작 주소 , 기본 블록 의 명령어 의 수 등 과 같 은 기본 블록 에 대한 정보 가 포함 될 수 있 다 . 따라서 , 만일 기본 블록 에 세 개 의 명령어 가 있 는 경우 , FTQ 엔트리 는 첫 번 째 명령어 의 주소 를 포함 할 수 있 고 , 또한 , 세 개 의 명령어 가 있 음 을 명시 하 여 페치 엔진 ( 144 ) 이 기본 블록 의 첫 번 째 주소 에서 시작 하 는 페치 해야 할 명령어 의 수 를 알 수 있 도록 한다 . 페치 엔진 ( 144 ) 은 상위 FTQ 엔트리 ( 132 ) 로 구성 된 FTQ ( 130 ) 의 헤드 를 읽 고 , 요구 페치 요청 ( demand fetch requests ) 의 0 이 아닌 정수 번호 N 을 I - cache 에 발행 하 며 , 여기 서 N 은 명령어 페치 폭 ( instruction fetch width ) 을 가리킨다 . 실행 에 따라 , 페치 엔진 ( 144 ) 은 후속 의 페치 요청 들 을 발행 하 기 전 에 응답 을 기다릴 수 있 다 . 이것 은 인 - 오더 ( in - order ) 페치 정책 에 해당 하 며 , 따라서 만일 요구 페치 신호 ( 145 ) 에 대응 하 는 명령어 들 이 L 1 I - 캐시 ( 162 ) 에서 발견 되 지 않 은 경우 , 요청 된 데이터 가 LLC ( 164 ) 에서 리턴 되 어 L 1 I - 캐시 ( 162 ) 에 기록 될 때 까지 페치 엔진 ( 144 ) 은 정지 ( stall ) 될 수 있 다 . 대안 적 인 예시 에서 , 비록 기본 블록 FTQ 엔트리 들 이 메모리 의 저장 공간 에 있 어서 더 경제 적 이 지만 , 각 FTQ 엔트리 또는 FTQ 엔트리 들 의 적어도 0 이 아닌 부분집합 ( subset ) 은 단일 명령어 주소 를 포함 할 수 있 다 .