MIPS 설계자가 시프트 전용 5 비트를 포함하고 별도의 opcode 및 기능 비트를 갖는 이유에 대해 혼란 스럽습니다.
MIPS는 RISC이기 때문에 몇 가지 명령으로 만 시프트를 수행한다고 가정하므로 5 비트는 즉시 배치 할 수있을 때 공간을 낭비하는 것처럼 보입니다. 나는 op-code와 funct가 R- 및 I-type 명령어를 구별하기 위해 별도로 있다고 가정하지만 opcode를 1 비트로 확장하여 수행 할 수 있습니다. 이러한 R- 타입 명령어는 22 비트 길이 일 수 있습니다. I- 타입 및 J- 타입 명령어가 즉시 주소를 유지하려는 경우에는 작동하지 않지만 둘 다 필요하지 않은 것 같습니다.
답변:
여기에는 몇 가지 다른 상충 관계가 있습니다.
먼저, 명령어를 고정 너비 (32 비트)로 만들고 싶습니다. 이는 명령어가 캐시 블록 및 페이지 정렬을 보장하여 캐시 및 페이지 존재 및 권한 검사를 단순화합니다.
둘째, 다양한 명령어 필드 ( opcode/ source regs/ immediates)를 고정 너비 및 고정 위치로 설정하려고합니다. 이로 인해 더 빠르고 적은 디코딩 로직이 가능하며 파이프 라인의 초기 단계에서 필요합니다. ( destination레지스터는 파이프 라인이 끝날 때까지 필요하지 않으므로 다른 위치 R와 I지침 에있을 수 있습니다 .) functionALU의 기능을 제어해야하기 때문에 필드 의 위치와 너비 는 조금 덜 중요합니다. 세 번째 파이프 라인 단계에서 필요한 경우 작업 할 시간이 조금 있습니다.
IJJI컴파일러 / 링커 작성자에게도 유용한 지침입니다. (직접 필드가 12 비트에 불과한 SPARC에서는 load-high20 비트 즉시 의 전체 특수 명령 클래스 를 추가해야했습니다 .)
JRI
그러나 R지시 사항 이있는 흔들리는 방이 남습니다 . 6 비트 opcode 외에도 레지스터 사양에 15 비트 만 추가하면되므로 확장 opcode 및 / 또는 shift-amount에는 11 비트가 남습니다.
이 function필드는 명령을위한 확장 된 opcode로 생각해야합니다 R. R명령어 opcode는 하나만 있지만 명령어가 수행 할 수 functions있는 64 가지 가 R있습니다.
괜찮아. 우리는 60 개의 다른 I명령과 64 개의 다른 R명령을 가지고 있습니다. 그래서 교대 즉시 명령을 어디에 두어야합니까?
글쎄, I지침 이 적을 뿐만 아니라 지침으로 더 많은 일을하고 싶습니다 I . 모든 분기 명령어 I는 상대 (즉시) 오프셋이 있으므로 명령어 여야 합니다. 또한 모든로드 및 저장 명령어는 IMIPS 형식입니다. 그리고 마지막으로 명령 즉시로드 즉시 명령이 필요합니다 I. 뿐만 아니라 R명령어에는 여전히 5 개의 추가 사용되지 않는 비트가 있습니다 (이 아키텍처에서 즉시 전환이 필요한 즉시 필요한 것입니다). 따라서 시프트 즉시를 특수 (이상한) R명령어 로 만드는 데 더 많은 동기가 부여됩니다 .
이러한 결정 중 많은 부분이 과학보다 더 예술적이지만 식별 할 수있는 기본 논리가 있습니다. 주요 목표는 하지 가능한 한 작게 지침의 수를 만들기 위해, 그것은 확인하는 것입니다 높은 성능을파이프 라인은 단일 칩에 적합합니다 (MIPS 및 Sun과 같은 소규모 회사는 1980 년대에 있었으므로 IBM 및 DEC와 경쟁 할 수 있음). (데이비드 패터슨 (David Patterson)이 발명 한 RISC라는 이름은 다소 유감스러운 일입니다. "축소 된 명령"이 MIPS 및 SPARC 아키텍처가 실제로하려는 작업에 대한 정확한 설명이 아니기 때문에 귀여웠 기 때문입니다.) 페치, 페이징 및 디코딩을 더 간단하고 빠르게 만들기 위해 고정 너비 (및 비교적 작은 I- 캐시 동작을 얻을 수 있도록)가 작습니다. 명령의 일부를 조기에 디코딩해야합니다 (opcode, 2 개의 소스 레지스터 및 부호 확장 즉시)는 고정 폭과 고정 위치에 있어야합니다. 즉시 가능한 한 오래되기를 원하며, 다른 모든 제약 조건을 고려할 때 가능한 많은 종류의 명령을 원합니다.
MIPS I 명령어 형식을 이해하려면 MIPS 파이프 라인을 이해하고 1985 년경 CPU 구현 기술을 다시 생각해야합니다. 다이어그램을 보면 (파일을 알고 있음) 레지스터 파일 읽기가 IF 직후 ID 단계.
R 유형 명령어의 목적을 위해 ID 단계는 다음 작업을 수행해야합니다.
이 토론의 목적 상 가장 먼저 고려해야 할 작업입니다. 레지스터의 값이 필요한 경우 해결해야하는 많은 명령 디코딩 작업이있는 경우 레지스터 읽기를 시작하기 전에 지연 시간이 늘어납니다. 또한 ID 단계의 복잡성을 증가시킵니다. 모든 R 유형 명령어에 대해 단일 opcode를 예약하면 복잡성을 최소한으로 유지할 수 있습니다.
시프트에 5 비트를 바치는 것이 조금 이상하게 보입니다. 몇 가지 가능한 설명을 생각할 수 있습니다. 하나는 라우팅을 단순화한다는 것입니다 (5 개의 비트는 항상 레지스터 파일에 직접 공급되고, 5 개의 비트는 항상 배럴 시프터에 공급되며, 6 개의 비트는 항상 수행 할 기능을 결정하기 위해 ALU로 라우팅됩니다).
그들은 미래에 조합 된 왼쪽 및 추가 명령을 도입하려고 생각했을 수도 있습니다. 이것은 아마도 다음과 같은 형식 일 것입니다.
$d = $s + ($t << shamt)
오늘날 우리는 더 복잡한 디코딩 단계에 대해 두 번 생각하지 않을 것입니다. 특히 레지스터 파일 액세스는 나중에 전형적인 슈퍼 스칼라 CPU의 파이프 라인에서 발생하기 때문입니다. 많은 현대 CPU는 심지어 명령어가 L1 캐시에 삽입 될 때 약간의 명령어 디코딩 을 수행 합니다 . I- 캐시 라인을 추가 정보 (무어의 법칙 덕분에 낭비 할 많은 트랜지스터가 있음)를 저장하기 위해 몇 비트 더 넓게 만들어 "적절한"명령어 디코딩을 더 간단하고 빠르게 만듭니다.
그들이 opcode 필드를 가능한 한 작게 유지하려는 이유 중 하나는 J 유형 명령어를 부당하게 처벌하지 않기 때문입니다. 아시다시피 J 유형 명령어는 의사 직접 주소 지정을 사용합니다. 집에서 같이 놀아주는 사람의 이익을 위해 간단히 설명하겠습니다.
J 형 명령어의 주소 필드는 26 비트입니다. 명령어는 항상 4 바이트로 정렬되므로 최하위 2 비트를 저장할 필요가 없으므로 28 비트 주소를 효과적으로 가질 수 있습니다. 그러나 MIPS I의 주소 공간은 32 비트입니다. 따라서 점프 위치의 상위 4 비트는 프로그램 카운터에서 가져옵니다.
즉, PC 위치의 최상위 4 비트가 다른 위치로 바로 이동할 수 없습니다. 대신 스크래치 레지스터를 통해 더 비싼 3 명령 점프를 수행해야합니다.
lui $r,target >> 16
ori $r,$r,target & 0xFFFF
jr $r
오늘날에는 그렇게 나쁘지는 않지만 1985 년에는 많은 클럭 사이클이 있습니다.
주소 필드에서 비트를 훔치면 직접 점프의 유효 범위가 훨씬 더 줄어 듭니다. 이것이 지불하기에는 너무 높은 가격을 볼 수 있습니다.