인텔 iAPX 432

섬네일|인텔 SBC 432/100 보드
섬네일|일반 데이터 프로세서 43201
섬네일|일반 데이터 프로세서 43202
**iAPX 432**(Intel Advanced Performance Architecture)는 1981년에 도입되었다가 단종된 컴퓨터 구조이다. 이는 인텔의 첫 번째 32비트 마이크로프로세서 설계였다. 이 아키텍처의 주 프로세서인 일반 데이터 프로세서(general data processor)는 당시의 기술적 한계로 인해 두 개의 별도 집적 회로 세트로 구현되었다. 마케팅상의 이유로 일부 초기 8086, 80186 및 80286 기반 시스템과 매뉴얼에서도 iAPX 접두사를 사용하기도 했으나, iAPX 432와 8086 프로세서 라인은 완전히 다른 명령어 집합을 가진 별개의 설계이다.

이 프로젝트는 1975년에 8008과 8080의 뒤를 잇는 **8800**이라는 이름으로 시작되었으며, 1980년대를 위한 인텔의 주요 설계가 될 예정이었다. 8080의 후계자로 다음 해에 설계된 8086과 달리, iAPX 432는 다른 시장 틈새를 겨냥한 인텔의 이전 설계들과는 근본적으로 궤를 달리하는 설계였으며, 8080이나 X86 제품군과는 전혀 관련이 없었다.

iAPX 432 프로젝트는 인텔의 상업적 실패작으로 간주되며, 1986년에 단종되었다.

## 설명
iAPX 432는 완전히 고수준 프로그래밍 언어로 프로그래밍되도록 설계된 "마이크로메인프레임"으로 지칭되었다. 명령어 집합 아키텍처 또한 완전히 새로웠으며, iAPX 432 프로그래밍 모델이 가시적인 범용 레지스터가 없는 스택 머신이라는 점에서 인텔의 이전 8008 및 8080 프로세서와 크게 달랐다. 이는 객체 지향 프로그래밍, 쓰레기 수집 및 다중작업뿐만 아니라 하드웨어 및 마이크로코드에서 직접 더 전통적인 메모리 관리를 지원한다. 다양한 자료 구조에 대한 직접적인 지원은 일반적인 프로세서보다 훨씬 적은 프로그램 기계어 코드를 사용하여 현대적인 운영체제를 구현할 수 있도록 의도되었다. 인텔 iMAX 432는 단종된 432용 운영체제로, 완전히 에이다로 작성되었으며, 에이다는 애플리케이션 프로그래밍을 위한 주된 언어로 의도되기도 했다. 어떤 측면에서 이것은 고수준 언어 컴퓨터 구조로 볼 수 있다.

이러한 특성과 기능은 당시 대부분의 프로세서, 특히 마이크로프로세서보다 더 복잡한 하드웨어 및 마이크로코드 설계를 초래했다. 그러나 내부 및 외부 버스는 (대부분) 16비트보다 넓지 않았으며, 68000과 같은 당시의 다른 32비트 마이크로프로세서에서와 같이 32비트 산술 명령어는 순차 논리나 마이크로코드 등을 통해 16비트 ALU로 구현되었다. 8080에 비해 확장된 iAPX 432의 주소 공간 또한 데이터의 선형 주소 지정이 여전히 16비트 오프셋만 사용할 수 있다는 점에 의해 제한되었는데, 이는 현대의 80286을 포함한 인텔의 첫 8086 기반 설계와 다소 유사했다(80386 아키텍처의 새로운 32비트 세그먼트 오프셋은 1984년에 상세히 공개되었다).

당시의 반도체 기술을 사용하여 인텔의 엔지니어들은 이 설계를 매우 효율적인 첫 구현으로 옮기지 못했다. 시기상조였던 에이다 컴파일러의 최적화 부족과 더불어, 이는 다소 느리지만 비싼 컴퓨터 시스템의 원인이 되었으며, 동일한 클럭 주파수(1982년 초)에서 새로운 80286 칩 속도의 약 1/4 정도의 벤치마크 성능을 보였다. 다소 저사양이고 가격이 저렴한 8086 라인과의 초기 성능 격차는 아마도 인텔이 후자(나중에 X86으로 알려짐)를 iAPX 432로 교체하려던 계획이 실패한 주된 이유였을 것이다. 엔지니어들은 차세대 설계를 개선할 방법을 찾았지만, iAPX 432의 기능 기반 보안 아키텍처는 이제 의도했던 단순화 지원이라기보다는 구현상의 오버헤드로 간주되기 시작했다.

원래 최대 10 MHz의 클럭 주파수를 위해 설계되었으나, 실제 판매된 장치는 최대 4 MHz, 5 MHz, 7 MHz, 8 MHz의 클럭 속도로 사양이 지정되었으며, 8 MHz에서 초당 200만 개의 명령어를 처리하는 최대 성능을 냈다.

## 역사

### 개발
인텔의 432 프로젝트는 8비트 인텔 8080이 완성된 지 1년 후이자 16비트 8086 프로젝트가 시작되기 1년 전인 1976년에 시작되었다. 432 프로젝트는 처음에 기존 인텔 8008 및 8080 마이크로프로세서를 넘어서는 다음 단계로서 **8800**이라는 이름이 붙었다. 이는 매우 큰 진보가 되었다. 이들 8비트 프로세서의 명령어 집합은 전형적인 알골류의 컴파일 언어에 잘 맞지 않았다. 그러나 주요 문제는 8008의 경우 고작 16 KB, 8080의 경우 64 KB인 작은 기본 주소 지정 범위였으며, 이는 뱅크 전환, 메모리 세그먼트 또는 유사한 메커니즘(몇 년 후 8086에 내장됨)을 사용하지 않고서는 많은 복잡한 소프트웨어 시스템에 사용하기에 너무 작았다. 인텔은 이제 구형 칩들로 가득 찬 캐비닛이 필요했던 당시 최고의 32비트 미니컴퓨터 및 메인프레임과 기능적으로 대등하거나 그보다 뛰어난 정교한 완전한 시스템을 몇 개의 LSI 칩에 구축하는 것을 목표로 했다. 이 시스템은 다중 프로세서, 모듈식 확장, 결함 허용, 고급 운영체제, 고급 프로그래밍 언어, 초대형 애플리케이션, 초고신뢰성 및 초보안을 지원할 것이었다. 그 아키텍처는 향후 10년 동안 인텔 고객의 요구를 해결할 것이었다.

iAPX 432 개발 팀은 빌 래틴이 관리했으며, 저스틴 래트너(나중에 인텔의 CTO가 됨)가 수석 엔지니어를 맡았다(한 소스에 따르면 프레드 폴락이 수석 엔지니어였다고 한다). 처음에 팀은 산타클라라에서 근무했으나, 1977년 3월에 래틴과 17명의 엔지니어 팀은 포틀랜드에 있는 인텔의 새로운 사이트로 이동했다. 폴락은 나중에 슈퍼스칼라를 전문으로 하여 펜티엄 프로의 수석 설계자가 되었다.

이 모든 것을 설계하는 데 수년과 많은 엔지니어가 필요하다는 것이 곧 분명해졌다. 그리고 개선된 반도체 제조 기술이 이 모든 것을 몇 개의 고밀도 칩에 담을 수 있기까지는 무어의 법칙에 따른 수년간의 추가적인 진보가 마찬가지로 필요했다. 그동안 인텔은 모토로라, 자일로그, 내셔널 세미컨덕터와의 즉각적인 경쟁에 대처하기 위해 더 간단한 임시 제품이 시급히 필요했다. 그래서 인텔은 별도의 설계 팀을 사용하여 8080으로부터 위험이 낮은 점진적 진화로서 8086을 설계하는 서두른 프로젝트를 시작했다. 대중 시장용 8086은 1978년에 출시되었다.

8086은 특수 어셈블러를 사용하여 8080 어셈블리어를 8086 아키텍처에 매핑할 수 있다는 점에서 8080과 하위 호환되도록 설계되었다. 기존의 8080 어셈블리 소스 코드(실행 코드는 아니지만)는 이로써 새로운 8086과 어느 정도 상향 호환되었다. 대조적으로 432는 소프트웨어 호환성이나 마이그레이션 요구 사항이 없었다. 설계자들은 대규모 시스템과 소프트웨어에 가장 적합하다고 추측되는 모든 기술을 사용하여 처음부터 새로운 설계를 할 수 있는 완전한 자유를 가졌다. 그들은 대학의 유행하는 컴퓨터 과학 개념들, 특히 기능 기반 주소 지정, 객체 지향 프로그래밍, 고수준 CISC 머신, 에이다, 고밀도로 인코딩된 명령어를 적용했다. 이러한 야심 찬 새로운 기능들의 혼합은 칩을 더 크고 복잡하게 만들었다. 칩의 복잡성은 클럭 속도를 제한하고 설계 일정을 연장시켰다.

설계의 핵심인 주 프로세서는 일반 데이터 프로세서(**GDP**)라고 불렸으며 두 개의 집적 회로로 구성되었다. 하나(43201)는 명령어를 인출하고 해독하며, 다른 하나(43202)는 이를 실행했다. 대부분의 시스템에는 I/O를 위한 채널 컨트롤러 역할을 하는 43203 인터페이스 프로세서(**IP**)와 "I/O 하위 시스템에 처리 능력을 제공하는" 전통적인 인텔 8086인 부착 프로세서(**AP**)가 포함되었다.

이들은 당시 가장 큰 설계들 중 일부였다. 2칩 GDP는 약 97,000개의 트랜지스터를 결합했으며 단일 칩 IP는 약 49,000개를 가졌다. 비교하자면 1979년에 도입된 모토로라 68000은 약 40,000개의 트랜지스터를 가졌다.

1983년에 인텔은 iAPX 432 상호 연결 아키텍처를 위한 두 개의 추가 집적 회로인 43204 버스 인터페이스 유닛(**BIU**)과 43205 메모리 제어 유닛(**MCU**)을 출시했다. 이 칩들은 최대 63개의 노드를 가진 거의 글루리스(glueless) 멀티프로세서 시스템을 가능하게 했다.

### 프로젝트의 실패
iAPX 432의 혁신적인 기능 중 일부는 좋은 성능에 해로웠다. 많은 경우 iAPX 432는 내셔널 세미컨덕터 32016, 모토로라 68010, 인텔 80286과 같은 당시의 전통적인 마이크로프로세서보다 현저히 느린 명령어 처리량을 보였다. 한 가지 문제는 GDP의 2칩 구현이 마더보드의 전기 배선 속도로 속도를 제한했다는 점이었다. 더 큰 문제는 기능 아키텍처가 효율적으로 실행되기 위해 큰 연관 캐시가 필요했지만 칩에 그럴 공간이 없었다는 것이었다. 또한 명령어 집합은 대부분의 컴퓨터 설계에서 사용되는 일반적인 반고정 바이트 또는 워드 정렬 형식 대신 비트 정렬 가변 길이 명령어를 사용했다. 따라서 명령어 해독이 다른 설계보다 더 복잡했다. 이것이 그 자체로 성능을 저하시키지는 않았지만, 캐시, 더 넓은 버스 및 기타 성능 지향적 기능을 위한 공간과 트랜지스터가 이미 부족한 설계에서 (주로 대형 배럴 시프터를 위해) 추가적인 트랜지스터를 사용하게 만들었다. 또한 BIU는 결함 허용 시스템을 지원하도록 설계되었으며, 그 과정에서 버스 시간의 최대 40%가 대기 상태에 묶여 있었다.

또 다른 주요 문제는 미성숙하고 튜닝되지 않은 에이다 컴파일러였다. 그것은 더 빠른 스칼라 명령어를 사용하는 것이 합리적인 경우에도 모든 경우에 고비용의 객체 지향 명령어를 사용했다. 예를 들어 iAPX 432에는 매우 비싼 모듈 간 프로시저 호출 명령어가 포함되어 있었는데, 컴파일러는 훨씬 더 빠른 분기 및 링크 명령어가 존재함에도 불구하고 모든 호출에 이를 사용했다. 또 다른 매우 느린 호출은 메모리 보호를 설정하는 enter_environment였다. 컴파일러는 변수가 기존 환경 내에서 사용되어 확인이 필요하지 않은 경우에도 시스템의 모든 단일 변수에 대해 이를 실행했다. 설상가상으로 프로시저로 전달되는 데이터는 참조가 아닌 항상 값-반환 방식(by value-return)으로 전달되었다. 드라이스톤 벤치마크를 실행할 때 매개변수 전달은 다른 모든 계산을 합친 것보다 10배 더 오래 걸렸다.

뉴욕 타임스에 따르면 "i432는 경쟁 제품인 모토로라 68000보다 5~10배 느리게 작동했다".

### 영향 및 유사한 설계
iAPX 432는 새로운 부동 소수점 산술을 위한 IEEE-754 표준을 구현한 최초의 시스템 중 하나였다.

432 실패의 한 가지 결과는 마이크로프로세서 설계자들이 칩의 객체 지원이 필연적으로 느리게 작동할 복잡한 설계로 이어진다는 결론을 내리게 된 것이며, 432는 RISC 설계 지지자들에 의해 반대 사례로 자주 인용되었다. 그러나 일부 사람들은 OO 지원이 432의 주된 문제가 아니었으며, 위에서 언급한 구현상의 단점(특히 컴파일러에서의)이 어떤 CPU 설계라도 느리게 만들었을 것이라고 주장한다. iAPX 432 이후 유사한 설계에 대한 시도는 Rekursiv 프로세서가 유일했으나, INMOS 트랜스퓨터의 프로세스 지원은 유사하면서도 매우 빨랐다.

인텔은 432에 상당한 시간과 비용, 그리고 마음 점유율을 쏟아부었고 이에 헌신하는 숙련된 팀을 보유하고 있었기에 시장에서의 실패 후에도 이를 완전히 포기하기를 꺼려했다. 새로운 설계자인 글렌포드 마이어스가 영입되어 핵심 프로세서를 위한 완전히 새로운 아키텍처와 구현을 생산했고, 이는 인텔/지멘스 공동 프로젝트(나중에 BiiN)로 구축되어 i960 시리즈 프로세서로 이어졌다. i960 RISC 하위 집합은 임베디드 프로세서 시장에서 한동안 인기를 끌었지만, 하이엔드 960MC와 태그가 달린 메모리를 사용하는 960MX는 군사 용도로만 마케팅되었다.

뉴욕 타임스에 따르면, HP와 인텔의 머세드 프로세서(나중에 아이테니엄으로 알려짐) 공동 개발은 초고성능 시장을 위한 인텔의 복귀 시도였다.

## 아키텍처
iAPX 432 명령어는 6비트에서 321비트 사이의 가변 길이를 갖는다. 특이하게도 이들은 바이트 정렬되지 않는다. 즉, 홀수 개의 비트를 포함할 수 있으며 바이트 경계에 관계없이 직접 서로를 뒤따른다.

### 객체 지향 메모리 및 기능
iAPX 432는 객체 지향 프로그래밍 및 기능 기반 주소 지정에 대한 하드웨어 및 마이크로코드 지원을 제공한다. 시스템은 세그먼트 메모리를 사용하며, 각각 최대 64 KB인 최대 224개의 세그먼트를 사용하여 총 240 바이트의 가상 주소 공간을 제공한다. 물리 주소 공간은 224 바이트(16 MB)이다.

프로그램은 주소로 데이터나 명령어를 참조할 수 없다. 대신 세그먼트와 세그먼트 내의 오프셋을 지정해야 한다. 세그먼트는 시스템 객체 테이블에 대한 인덱스와 해당 세그먼트에 대한 액세스를 제어하는 권한 세트(기능 기반 보안)를 제공하는 액세스 기술자(AD)에 의해 참조된다. 세그먼트는 액세스 기술자만 포함할 수 있는 "액세스 세그먼트"이거나 AD를 포함할 수 없는 "데이터 세그먼트"일 수 있다. 하드웨어와 마이크로코드는 데이터와 액세스 세그먼트 사이의 구분을 엄격하게 강제하며, 소프트웨어가 데이터를 액세스 기술자로 취급하거나 그 반대로 취급하는 것을 허용하지 않는다.

시스템 정의 객체는 단일 액세스 세그먼트 또는 액세스 세그먼트와 데이터 세그먼트로 구성된다. 시스템 정의 세그먼트는 지정된 오프셋에 시스템 정의 데이터에 대한 데이터 또는 액세스 기술자를 포함하지만, 운영체제나 사용자 소프트웨어가 이를 추가 데이터로 확장할 수 있다. 각 시스템 객체에는 마이크로코드에 의해 확인되는 유형 필드가 있어 포트 객체가 사용되어야 할 곳에 캐리어 객체가 사용될 수 없도록 한다. 사용자 프로그램은 유형 제어 객체(TCO)를 사용하여 하드웨어 유형 확인의 모든 이점을 누릴 수 있는 새로운 객체 유형을 정의할 수 있다.

iAPX 432 아키텍처의 릴리스 1에서 시스템 정의 객체는 일반적으로 액세스 세그먼트와, (객체 유형에 따라 선택적으로) 액세스 세그먼트 내의 고정된 오프셋에 있는 액세스 기술자에 의해 지정된 데이터 세그먼트로 구성되었다.

아키텍처 릴리스 3에서는 성능 향상을 위해 액세스 세그먼트와 데이터 세그먼트가 각각 0–64 KB의 액세스 부분과 데이터 부분으로 나뉜 최대 128 kB의 단일 세그먼트로 결합되었다. 이를 통해 객체 테이블 조회 횟수가 획기적으로 줄어들고 최대 가상 주소 공간이 두 배로 늘어났다.

iAPX432는 14가지 유형의 사전 정의된 시스템 객체를 인식한다.
* **명령어 객체(instruction object)**: 실행 가능한 명령어를 포함한다.
* **도메인 객체(domain object)**: 프로그램 모듈을 나타내며 서브루틴 및 데이터에 대한 참조를 포함한다.
* **컨텍스트 객체(context object)**: 실행 중인 프로세스의 컨텍스트를 나타낸다.
* **유형 정의 객체(type-definition object)**: 소프트웨어 정의 객체 유형을 나타낸다.
* **유형 제어 객체(type-control object)**: 유형별 권한을 나타낸다.
* **객체 테이블(object table)**: 시스템의 활성 객체 기술자 컬렉션을 식별한다.
* **저장 자원 객체(storage resource object)**: 여유 저장소 풀을 나타낸다.
* **물리 저장 객체(physical storage object)**: 메모리의 여유 저장소 블록을 식별한다.
* **저장 청구 객체(storage claim object)**: 관련된 모든 저장 자원 객체에 의해 할당될 수 있는 저장소를 제한한다.
* **프로세스 객체(process object)**: 실행 중인 프로세스를 식별한다.
* **포트 객체(port object)**: 프로세스 간 통신을 위한 포트 및 메시지 큐를 나타낸다.
* **캐리어(carrier)**: 포트 간에 메시지를 운반한다.
* **프로세서(processor)**: 시스템 내 한 프로세서의 상태 정보를 포함한다.
* **프로세서 통신 객체(processor communication object)**: 프로세서 간 통신에 사용된다.

### 쓰레기 수집
432에서 실행되는 소프트웨어는 더 이상 필요하지 않은 객체를 명시적으로 할당 해제할 필요가 없다. 대신 마이크로코드는 에츠허르 데이크스트라의 즉석 병렬 쓰레기 수집 알고리즘(마크-앤-스윕 스타일 수집기)의 마킹 부분을 구현한다. 시스템 객체 테이블의 항목에는 수집기에 필요한 대로 각 객체를 흰색, 검은색 또는 회색으로 표시하는 데 사용되는 비트가 포함되어 있다. iMAX 432 운영체제에는 쓰레기 수집기의 소프트웨어 부분이 포함되어 있다.

### 명령어 형식
실행 가능한 명령어는 시스템 "명령어 객체" 내에 포함된다. 명령어가 비트 정렬되어 있기 때문에 명령어 객체에 대한 16비트 비트 변위(displacement)를 통해 객체는 최대 65,536비트(8,192바이트)의 명령어를 포함할 수 있다.

명령어는 클래스와 연산 코드(opcode)로 구성된 연산자(operator)와 0개에서 3개의 피연산자 참조로 구성된다. "필드는 해독에 필요한 순서대로 프로세서에 정보를 제공하도록 구성된다." 더 자주 사용되는 연산자는 더 적은 비트를 사용하여 인코딩된다. 명령어는 피연산자의 수(명령어의 차수라고 함)와 각 피연산자의 길이를 나타내는 4비트 또는 6비트 클래스 필드로 시작한다. 뒤이어 선택적으로 피연산자를 설명하는 0~4비트 형식(format) 필드가 온다(피연산자가 없으면 형식은 존재하지 않음). 그다음 형식에 설명된 대로 0~3개의 피연산자가 온다. 명령어는 0~5비트의 연산 코드가 있으면 그것으로 종료된다(일부 클래스에는 명령어가 하나만 포함되어 있어 연산 코드가 없는 경우도 있음). "형식 필드는 GDP가 프로그래머에게 0개, 1개, 2개 또는 3개 주소 아키텍처로 보이게 한다." 형식 필드는 피연산자가 데이터 참조인지, 피연산자 스택의 맨 위 또는 맨 위에서 두 번째 요소인지를 나타낸다.

## 각주

; 내용주


## 외부 링크
*  IAPX 432 manuals at Bitsavers.org

분류:인텔의 마이크로프로세서