2P by GN⁺ | ★ favorite | 댓글 1개
  • Intel 80386은 x86 최초의 32비트 CPU를 넘어 4GiB 플랫 메모리와 기존 x86 호환성을 함께 제공해 PC용 현대 운영체제의 기반이 됨
  • Intel은 처음엔 iAPX 432와 P7 같은 다른 아키텍처에 더 무게를 뒀지만, PC 시장 성장과 x86 소프트웨어 호환성 때문에 386 완성을 최우선으로 돌림
  • 386에서 Intel은 IBM·AMD의 세컨드 소스 생산을 허용하지 않고 단독 공급자가 되었으며, Compaq Deskpro 386은 IBM 중심의 PC 표준 흐름을 흔듦
  • 성능은 동시대 RISC 칩보다 압도적이지 않았지만, 모든 386 모델에 들어간 MMU와 Virtual 8086 모드가 UNIX, OS/2, Windows, NT, Linux 전환의 핵심이 됨
  • 386 기반 PC가 대량 생산되며 MMU가 일반 사용자용 PC까지 확산됐고, Windows의 대중화와 Linux의 탄생도 386의 보급과 강하게 연결됨

Intel이 원하지 않았던 32비트 x86

  • Intel 80386은 x86 계열 최초의 32비트 CPU였지만, 초기 Intel의 핵심 계획은 아니었음
  • 1970년대 말 Intel의 가장 중요한 프로젝트는 1980년대 주력 설계로 의도된 iAPX 432였음
    • iAPX 432는 ADA 같은 고수준 언어에 맞춰 객체지향 프로그래밍과 저장소 할당을 하드웨어로 제공하려는 야심적인 CPU였음
    • 설계 성숙에 시간이 오래 걸릴 것으로 보여 Intel은 1976년에 임시 설계로 8086을 시작함
  • 8086 계열은 IBM PC 계약을 따냈고, iAPX 432는 1981년에 늦게 등장했지만 성능이 실망스러웠음
    • 같은 주파수의 훨씬 저렴한 80286보다 벤치마크에서 약 1/4 속도에 그침
  • 1982년에도 Intel은 PC 플랫폼과 소프트웨어 바이너리 호환성의 중요성을 충분히 인정하지 않았고, 80286도 또 하나의 임시 CPU에 가까웠음
  • Intel 엔지니어들은 432 계열의 실패를 인식한 뒤 P7이라는 32비트 RISC 아키텍처를 새로 준비하기 시작함

80386 설계 방향 확정

  • 286 설계자 중 한 명인 Bob Childs는 비공식적으로 286의 32비트 확장 아이디어를 정리함
  • 약 6개월 뒤 Intel은 P7이 준비되기 전에 x86 계열의 또 다른 반복이 필요하다고 판단했고, 386 개발을 승인함
    • 초기 팀은 작고 예산도 제한적이었음
    • x86 고객 요구를 조사한 결과, 8086의 세그먼트 메모리 방식은 널리 불만을 샀고 80286도 이를 없애지 못했다는 아쉬움이 남아 있었음
  • UNIX가 더 저렴한 워크스테이션에서 중요해지면서, 386 팀은 UNIX에 적합한 CPU를 목표로 삼음
  • 가장 중요한 요구는 플랫 메모리 주소 지정이었음
    • 기존 x86 호환성을 유지하기 위해 386도 세그먼트 구조를 유지함
    • 각 세그먼트가 4GiB까지 가능해지면서 세그먼트의 존재감은 사실상 줄어듦
    • 페이징과 가상 메모리 제공도 이 시기에 결정됨
  • 기존 명령어 집합과 레지스터를 32비트로 확장해 바이너리 호환성을 유지함
    • 별도의 “모드 헤더” 뒤에 완전히 다른 명령어 집합을 두는 방식은 택하지 않음
    • 대신 x86의 약점이던 적은 레지스터 수는 늘릴 수 없었음
  • 한때 P7용 새 버스 사용도 검토됐지만, 286 버스와 너무 달라 메인보드와 지원 칩 재설계가 필요했기 때문에 포기됨
    • 기존 버스를 32비트로 확장하는 덜 야심적인 방식이 선택됨
  • 1984년 무렵 PC 시장이 성장하면서 Intel은 x86 계열의 중요성을 이해했고, 80386 완성이 최우선 과제가 됨
    • P7 프로젝트는 1988년 i960으로 이어졌고, 386 판매를 잠식하지 않도록 임베디드 시장으로 목표가 바뀜

Intel의 386 단독 공급 전략

  • 80386은 1985년 10월에 발표됨
  • 당시에는 Intel 같은 칩 설계 회사가 CPU를 다른 회사도 생산할 수 있게 라이선스해 세컨드 소스를 마련하는 일이 일반적이었음
    • 고객은 주 공급자의 수율 문제가 생겨도 CPU 부족을 피할 수 있었음
    • Intel과 AMD는 8085 시절부터 긴 협력 관계를 유지했고, 서로 제품을 교차 라이선스했음
    • IBM도 1983년부터 808x와 80286을 직접 생산할 라이선스를 갖고 있었음
  • 80386에서는 이 관행이 바뀜
    • Intel은 PC에서 가장 가치 있는 부품인 CPU를 직접 통제하려면 단독 공급자가 되는 것이 중요하다고 봄
    • IBM은 미래 386보다 286에 대규모 투자하는 데 더 관심이 있었음
    • Intel과 IBM의 합의는 286에 대해 IBM을 만족시키는 방향으로 재협상됐지만, IBM은 386을 생산할 수 없었음
  • AMD도 386 생산에 큰 관심이 없었고, AMD와의 세컨드 소스 합의는 386으로 확장되지 않음
  • 비슷한 시기 NEC 대 Intel 사건에서 마이크로코드에 저작권이 있으며 Intel의 특정 라이선스 없이 복사할 수 없다는 판결이 나옴
    • NEC가 8086 마이크로코드를 리버스할 수 있었다 해도, 386은 복잡성 때문에 거의 불가능한 대상으로 다뤄짐
  • 이 흐름 이후 Intel은 Microsoft와 함께 PC 시장의 미래를 통제할 위치에 섬

Compaq Deskpro 386과 클론 PC의 승리

  • IBM PC는 빠르게 시장에 출시되기 위해 기성 부품을 사용했고, 그 결과 다른 회사도 같은 부품을 사서 호환기를 만들 수 있었음
  • 가장 성공적이고 야심적인 클론 업체는 Compaq이었음
    • 당시 Compaq은 매출 1억 달러에 가장 빠르게 도달한 회사였음
  • Compaq은 Intel이 80386을 출시한 지 거의 1년 뒤인 1986년 9월에 Deskpro 386을 발표함
    • Deskpro 386은 첫 386 컴퓨터였음
    • IBM이 286 기반 PC/AT로 PC 시장 통제력을 되찾으려는 흐름을 따르지 않은 첫 PC이기도 했음
  • Bill Gates는 IBM이 386을 신뢰하지 않았고, Microsoft가 Compaq에 386 기계를 만들도록 독려했다고 말함
    • 이 사건은 IBM만이 표준을 정하는 것이 아니라, Compaq과 Intel 같은 회사도 새로운 일을 할 수 있음을 보여준 전환점이 됨
  • Compaq Deskpro 386은 처음에는 매우 비쌌지만 판매는 준수했고, IBM이 더 이상 선두 자리에 있지 않음을 보여줌
  • IBM은 거의 1년 뒤에야 첫 386 컴퓨터인 PS/2 model 80을 내놓음
    • PS/2 라인은 당시 매우 진보적인 독자 버스를 도입해 통제를 되찾으려 했음
    • 그러나 IBM은 더 이상 자신의 방식을 강제할 위치에 있지 않았고, PS/2 라인은 그 임무를 달성하지 못함

386의 경쟁 환경과 성능

  • 1985년 Intel x86 계열의 주요 경쟁자는 Motorola 680x0 계열이었음
    • 많은 사람들은 68000이 8086보다 훨씬 우수한 칩이라고 봤고, 80286은 깨끗한 아키텍처로 진화할 기회를 놓쳤다고 여겼음
    • 68020은 Motorola CPU의 자연스러운 32비트 진화였음
  • 80386으로 Intel은 처음으로 진지한 경쟁자를 갖게 됨
    • 통합 MMU와 4GiB 플랫 주소 공간을 통해 수익성 높은 워크스테이션 시장도 겨냥할 수 있었음
  • 워크스테이션 시장에서는 많은 회사가 RISC 설계를 도입하고 있었음
    • RISC는 더 빠르고 더 저렴하게 만들 수 있다는 매력이 있었음
    • 386은 복잡한 x86 명령어 집합과 80286 주소 지정 모드를 처리하기 위해 두꺼운 마이크로코드에 의존하는 CISC 설계였음
  • 벤치마크에서 386은 평균적인 성능을 보임
    • Intel 80386 16MHz는 4 MIPS, 25MHz는 6 MIPS였음
    • Motorola 68030 25MHz도 6 MIPS였음
    • Mips R2000 16MHz는 16 MIPS, Motorola 88000 16MHz는 17 MIPS, Intel i960CA 33MHz는 66 MIPS였음
  • 성능이 획기적이지는 않았지만, 경쟁에 필요한 기능은 갖췄음

386SX와 32비트 소프트웨어 확산

  • Intel은 386에 완전히 전념한 뒤 1988년 386SX를 도입함
  • 386SX는 내부적으로 원래의 386과 동일했고, 원래 386은 386DX로 이름이 바뀜
    • 외부 데이터 버스는 16비트였음
    • 저렴한 플라스틱 패키지로 제공됨
    • 저렴한 16비트 메인보드에 꽂을 수 있었음
  • 386SX의 주요 목표는 비슷한 가격대의 286을 대체하는 것이었음
    • 286에는 여전히 세컨드 소스 공급자가 있었음
  • 1990년대 초에는 386 설치 기반이 충분히 커져 더 많은 소프트웨어 업체가 32비트 기능과 현대적 기능을 활용할 수 있게 됨
  • 저가형을 포함한 모든 386 모델에 통합 MMU가 들어간 점이 결정적이었음

MMU가 바꾼 메모리 관리

  • MMU는 Memory Management Unit의 약자로, 가상 주소를 물리 주소로 자동 변환하는 하드웨어임
  • 초기 프로그램은 기계의 전체 주소 공간을 볼 수 있었음
    • 주소 공간이 작을 때는 관리 가능했지만, 여러 프로그램이 동시에 실행되고 운영체제가 ROM에 머물 수 없게 되면서 격리 문제가 커짐
  • 초기 해법 중 하나는 세그먼테이션이었음
    • 세그먼트 레지스터가 기준 주소 역할을 함
    • 프로그램이 주소에 접근하면 16비트 값이 세그먼트 레지스터에 더해져 물리 주소가 만들어짐
    • 세그먼트 크기 제한을 넘으면 fault가 발생해 프로그램 간 격리가 가능해짐
    • 8086은 메모리 접근에 세그먼트 방식을 사용함
  • 80286은 더 복잡한 메모리 관리를 지원하는 기능 풍부한 세그먼트 MMU를 갖췄고, 최대 16MiB 메모리에 접근할 수 있었음
    • OS/2 1.x는 이 MMU를 활용해 더 현대적인 경험을 제공함
  • PC 프로그래머에게 세그먼트 메모리는 제한이 많고 다루기 어려웠음
  • 더 현대적인 MMU 설계는 페이징을 중심으로 함
    • MMU는 가상 주소 공간을 고정 크기 페이지로 나눔
    • 페이지 접근 시 페이지 디스크립터를 읽어 물리 주소 변환 정보를 얻음
    • 페이지 디스크립터는 보통 메모리에 있으므로, 성능을 위해 최근 접근 디스크립터를 담는 TLB 캐시가 사용됨
  • 많은 현대 OS, 특히 UNIX 포트는 페이징과 더 잘 맞았음
    • 68000 기반 워크스테이션은 MC68451 대신 자체 페이징 외부 MMU를 사용하기도 함
    • Motorola는 68020용 외부 MMU인 68851을 도입함

80386 MMU의 구조와 차별점

  • 386은 현대 OS에 적합해야 하면서도 8086, 80286 및 기존 x86 소프트웨어와 호환되어야 했음
  • 이를 위해 386 MMU는 거의 별개의 두 장치처럼 구성됨
    • 하나는 세그먼트 모드용 장치
    • 다른 하나는 페이징 모드용 장치
  • 두 장치는 연쇄적으로 동작함
    • 논리 주소가 먼저 세그먼트 장치를 거쳐 선형 주소로 계산됨
    • 페이징이 꺼져 있으면 이 선형 주소가 곧 물리 주소가 됨
    • 페이징이 켜져 있으면 TLB나 메모리에서 페이지 디스크립터를 가져와 실제 물리 주소를 생성함
  • 세그먼트 장치는 비활성화할 수 없지만, 주소 0에서 시작하는 4GiB 세그먼트로 전체 메모리 공간을 표현해 플랫 메모리처럼 사용할 수 있음
  • 페이징 장치는 세그먼트를 4KiB 페이지로 나눔
  • 80386은 네 가지 권한 수준인 rings를 도입함
    • 권한 있는 메모리를 권한 없는 읽기·쓰기에서 보호하는 데 쓰임
    • 현대 보호 OS가 기반으로 삼는 기본 요소 중 하나였음
  • MMU는 Virtual 8086 모드에도 관여함
    • 8086 프로그램이 최대 1MiB 메모리를 가진 8086 전체를 제어하는 것처럼 실행됨
    • 여러 V86 가상 머신이 동시에 동작할 수 있음
    • 보호 자원 접근 같은 동작은 인터럽트를 발생시키고, 권한 있는 소프트웨어가 처리함
  • 386 MMU는 CPU의 통합되고 정돈된 일부로 설계됨
    • 이상적인 조건에서는 메모리 접근 성능에 영향을 주지 않음
    • MC68851은 항상 최소 1사이클 지연을 추가함
  • 68000 계열에서는 MMU가 항상 존재하지 않았음
    • 68020은 외부 MMU가 필요했음
    • 68030과 68040의 저가형 EC 버전은 통합 MMU가 없었음
  • 80386은 저가형 386SX까지 모든 모델에 MMU가 포함됨
    • MMU와 고급 동작 모드를 활용하는 프로그램이 어떤 386에서도 실행될 수 있었음

386이 연 운영체제 전환

  • 386의 진짜 영향력은 원시 성능보다 PC에서 현대 운영체제를 가능하게 한 데 있었음
  • Xenix

    • Xenix는 Microsoft와 SCO의 협력에서 시작된 마이크로컴퓨터용 초기 UNIX 포트 중 하나였음
    • 1980년에 8086 포트가 발표됐지만, 진정한 MMU가 없어 메모리 보호와 사용자 공간·커널 공간 분리가 불가능했음
    • 286 버전은 보호 모드를 활용해 워크스테이션의 UNIX에 더 가까워짐
    • 1987년 386 포트는 페이징을 사용해 격차를 줄였고, x86에서 실행되는 첫 현대적 32비트 OS가 됨
  • OS/2

    • OS/2는 처음에는 Microsoft와 IBM의 공동 개발이었고, 이후 Microsoft는 Windows에 집중하기 위해 떠남
    • 1987년에 출시됐지만 초기 버전은 286을 목표로 했음
    • IBM PS/2 라인의 다수가 286을 탑재했기 때문임
    • 보호 모드를 잘 활용했고 당시 고급 OS로 여겨짐
    • OS/2가 32비트 OS가 된 것은 1992년 버전 2.0부터였음
    • 그 전까지는 세그먼트 메모리 방식과 Virtual 8086 모드 부재로 DOS 애플리케이션 지원이 좋지 않았고 Windows/386에도 뒤처짐
    • OS/2 2.0은 개인용 컴퓨터에서 널리 사용된 첫 32비트 OS였음
  • Windows

    • Windows는 1987년 Windows/386부터 80386 전용 운영 환경을 제공함
    • Windows/386은 여전히 16비트 OS였고 32비트 플랫 메모리 공간을 노출하지 않았음
    • 대신 386 기능을 사용해 DOS 세션을 Virtual 8086 모드로 가상화함
    • 여러 DOS 세션이 서로를 의식하지 않고 병렬 실행될 수 있었음
    • DOS 소프트웨어에 의존하던 많은 기업에 중요했음
    • MMU 덕분에 EMS를 에뮬레이션하는 보호 모드 드라이버를 통해 확장 메모리도 제공됨
    • Windows 3.0과 Windows 3.1에서 이 흐름이 개선됐고, Windows 3.1은 큰 성공을 거둠
    • 1993년 Windows for Workgroups 3.11은 386 미만 CPU 지원을 중단했고, 파일 접근과 많은 드라이버가 32비트가 됨
    • Windows 95는 386 MMU를 본격 활용함
      • 플랫 메모리 공간을 노출함
      • 페이징과 가상 메모리를 사용함
      • 일부 코드는 여전히 16비트였지만 DOS는 거의 부트로더에 가까운 역할로 줄어듦
  • Windows NT

    • 첫 Windows NT는 1993년 7월 출시됨
    • Windows 95가 Windows 3.11에서 발전하며 일부 16비트 레거시 코드를 유지한 것과 달리, NT는 처음부터 “순수” 32비트 Windows를 목표로 새로 개발됨
    • NT의 주요 특징 중 하나는 하드웨어 독립성이었지만, 가장 중요한 포트는 80386용이었음
    • 페이징, supervisor mode, 메모리 보호를 본격 사용함
    • NT는 Windows 95와 거의 같은 API를 공유해 많은 Win32 애플리케이션을 실행할 수 있었음
    • NT4는 1990년대 중반 Workstation UNIX 시장에 영향을 주기 시작함
    • Windows 11은 NT 커널의 직접적인 후손임
  • Linux

    • 386과 가장 밀접하게 연결된 운영체제는 Linux
    • Linus Torvalds는 1991년 1월 무렵 새 386 PC를 구입함
    • Linus는 68008 칩에서 자란 컴퓨터 순수주의자로서 PC를 싫어했지만, 386이 등장하면서 PC가 매력적으로 보이기 시작했다고 말함
    • 386은 68020이 하던 일을 할 수 있었음
    • 1990년에는 대량 생산과 저렴한 클론 도입으로 훨씬 싸졌음
    • 이 386 PC는 운영체제 내부를 가르치기 위한 작은 UNIX 클론인 Minix를 실행하기에 적합했음
    • Linus는 Minix의 터미널 에뮬레이터에 만족하지 못해 직접 작성하기 시작함
    • 대학 컴퓨터에 접속하기 위해 좋은 터미널이 중요했음
    • 386 하드웨어를 배우기 위해 베어메탈 방식으로 작성함
    • 키보드 입력과 화면 출력 기능을 만들었음
    • 두 개의 독립 스레드를 중심으로 설계하면서 작은 task switcher를 작성함
    • 프로그램을 다운로드하려면 저장할 디스크 드라이버가 필요했고, 기능이 하나씩 추가되며 Linux로 알려질 운영체제가 형성됨
    • 1991년 중반 Linus는 POSIX 명세 사본을 요청했고, 1991년 8월 25일 comp.os.minix 뉴스그룹에 새 운영체제를 작업 중이라고 알림
    • 당시 표현은 “just a hobby, won’t be big and professional like gnu”였음

80386의 장기적 영향

  • 80386은 x86 계열에서 가장 중요한 CPU로 평가됨
  • 기술적으로 80386은 좋은 칩이었지만, 성능 면에서는 획기적이지 않았고 동시대 RISC 칩보다 뒤처졌음
  • 핵심은 현대적이고 빠른 MMU와 여러 동작 모드였음
    • 4GiB 플랫 메모리에 접근할 수 있었음
    • 기존 x86 소프트웨어와 호환성을 유지함
    • Windows가 점진적으로 현대화될 수 있었음
  • 386의 메모리 처리 능력은 충분히 좋았기 때문에, 후속 CPU들은 더 강력해졌지만 거의 20년 동안 이 영역에서 큰 추가를 하지 않았음
  • Linux 메인라인은 2013년에야 i386 지원을 중단함
  • 상업적으로도 386의 중요성은 컸음
    • Intel은 처음에는 32비트 x86 수요를 믿지 않았지만, x86이 미래임을 깨달음
    • 이 변화는 시장에 x86이 계속될 것이라는 신호를 줌
    • 주요 클론 업체들의 386 채택은 IBM을 밀어내고 신뢰할 수 있는 개방형 대안이 있음을 보여줌
    • Intel은 가장 강력한 x86 CPU의 유일한 공급자가 되며 CPU 시장 지배로 가는 중요한 단계를 밟음
  • 386 기반 기계가 대량 생산되며 가격이 빠르게 하락했고, MMU 접근이 대중화됨
    • Windows는 수백만 명에게 현대적 컴퓨팅을 소개함
    • NT 커널은 저렴한 “베이지색” PC에서도 견고한 OS가 실행될 수 있음을 보여줌
    • Linux는 386 없이는 존재하지 않았다고 말할 수 있을 정도로 386과 강하게 연결됨

댓글과 토론

Hacker News 의견들
  • 80386 최종 설계는 Motorola 68000과 뒤이은 m68020 덕을 크게 봤다고 생각함
    Motorola가 타협 없는 제대로 된 32비트 CPU를 내놓지 않았다면, Intel은 80286 뒤에도 또 하나의 임시방편을 냈을 가능성이 있음. 80286 자체도 8086/8088의 제대로 된 후계자로 의도된 건 아니었음
    실제 80386에도 타협이 많았음. 16바이트 명령어 선인출 큐 말고는 캐시가 전혀 없었고, m68020에는 256바이트 명령어 캐시가 있었음. 원자적 명령어도 없었고, LOCK은 여기에 별로 쓸모가 없었기 때문에 요즘 많은 OS가 80486은 지원해도 80386은 지원하지 않음. 8086 호환성 때문에 실제 모드나 VM86이 필요했던 탓에, 소프트웨어가 80386의 새 기능을 활용하기까지 꽤 오래 걸렸음
    그래도 중요한 칩이었고, 이후 Intel에서 익숙해진 패턴의 초기 징후도 보여줬음. x86과 경쟁하지 않거나 x86을 희생해 다른 시장을 만들려던 시도(iAPX 432, 20년 뒤 Itanic), 80286에 붙은 기능처럼 급히 덧붙인 뒤 영원히 레거시 지원으로 끌고 가야 했던 기능들, 다른 업체가 모두가 원하는 기능을 갖고 있을 때 뒤늦게 따라잡는 모습(당시의 평탄한 32비트 지원, 20년 뒤의 64비트 지원) 같은 것들임

    • Linus Torvalds가 첫 Linux 커널을 작성한 머신이 386이었고, Linux가 처음부터 386의 새 기능을 지원한 점이 빠르게 뜬 이유 중 하나였음
    • 386에 원자적 명령어가 없었던 게 정말 중요했는지는 의문임. 386에는 대칭형 다중 처리(SMP)가 없었던 것으로 알고 있고, 단일 프로세서 환경에서는 인터럽트를 끄면 연산을 원자적으로 만들 수 있음
  • 당시 Intel은 큰 위기에 있었고, 회사 전체가 이 칩이 훌륭하게 나오는 데 걸려 있었음
    Data General, Honeywell, CDC, AST, Tandy, Olivetti, Xerox, DEC Rainbow, AT&T Hobbit, Wang 2200, Unisys처럼 쉽게 빗나갈 수도 있었음. 여기에는 강한 생존자 편향이 있음. SDS, SDC, Fairchild 같은 한때의 거인 대부분은 지금은 거의 잊힌 상태임
    Intel의 역사는 원래 메모리 제조사에 가까웠음. 지금도 비슷하게 곤란한 위치에 있다고 볼 수 있음. 모바일과 가전 시장 점유율은 사실상 0%이고, 남은 핵심 거점에서도 NVIDIA, AMD, ARM이 성을 약탈하듯 밀어붙이고 있음. 이번에도 빠져나오길 바람

    • Andy Grove가 Intel을 메모리에서 마이크로프로세서로 옮긴 건 탁월한 전략적 결정이었음
      “사업의 성공은 자기 파괴의 씨앗을 품고 있다. 성공은 안일함을 낳고, 안일함은 실패를 낳는다. 편집증 환자만이 살아남는다”
      2010년대 Intel 경영진은 이 말을 충분히 신경 쓰지 않았음
    • DEC Rainbow는 전용 플로피 디스크를 개당 5달러에 사게 만드는 짓만 안 했어도 괜찮았을 것임
      DEC는 LSI-11을 소비자용 머신으로 포장했어야 함. 소프트웨어도 다 있었고 수준도 아주 높았음. H-11을 갖고 있었는데 훌륭한 머신이었음
    • NVIDIA는 좋은 CPU를 만들지 못하고, SoC조차 최신 수준이라고 하긴 어려움. 자동차 업계처럼 부품 장기 공급만 신경 쓰는 곳과 Nintendo Switch 말고는 대중 시장 채택도 거의 없음
      Switch가 여전히 2015년대 Tegra 칩셋을 쓰는 것도, Nintendo 정도로 큰 회사조차 NVIDIA를 밀어붙여 새 설계를 끌어내지 못했기 때문일 가능성이 큼. ARM은 일반에 널리 살 수 있는 서버 CPU를 만들지 않고, 존재하는 제품도 클라우드 업체들이 다 가져감. Mac 바깥에서는 쓸 만한 ARM 데스크톱·노트북 CPU도 없음. Qualcomm이 그 시장을 몇 년은 망쳐놨기 때문임
      ARM이 Rosetta와 경쟁할 만한 해법을 내놓고, Qualcomm이 “간신히 돌아가면 출시”라는 스마트폰 업체에는 통할지 몰라도 PC/데스크톱 시장에는 안 맞는 사고방식에서 벗어나지 않는 한, 그 시장에서 ARM 채택은 어려워 보임
      결국 Intel에 남은 유일한 위협은 AMD인데, AMD는 Intel의 해자를 충분히 위협할 만큼의 팹 생산능력이 없음. 범용 컴퓨팅 경쟁 상태에 매우 답답할 수도 있고 아닐 수도 있음
    • 지금 Intel의 희망은 뭘까? Dothan 같은 식의 Quark 파생 데스크톱 CPU라도 있는 건가?
  • 386에 “평탄한 32비트”라는 후대식 해석을 덧씌우는 건 그만했으면 함. 그게 명백한 목표는 아니었고, 당시 미래로 여겨졌던 중요한 능력 기반 아키텍처 기능을 받아들이는 쪽에 가까웠음
    Unix/C/RISC/단일 감독자 모델 같은 아이디어가 보안 같은 영역에서 이전 30년간의 메인프레임·미니컴퓨터 OS 연구를 밀어내기 전의 맥락임
    이 글이 제대로 분명히 하지 않는 점은, 세그먼트 레지스터가 이제 기본적으로 기준 주소+길이(페이지 또는 바이트 단위) 필드와 실행 권한 제어를 가진 테이블의 선택자 인덱스가 됐다는 것임. 그리고 이런 선택자와 GDT/LDT/IDT/TSS/호출 게이트/태스크 게이트 등은 모두 4단계 권한 계층, 예를 들면 사용자/라이브러리/드라이버/커널을 지원하도록 설계됐음
    접근 선택자를 주고받으면서 자료구조 크기 제한 같은 것을 강제할 수도 있었고, 이를 위해 FS/GS를 추가해 범용 레지스터마다 자체 권한 마스크를 가질 수 있게 했음
    잠깐 다시 생각해보면, 포인터(능력, 즉 선택자)는 기준 주소뿐 아니라 하드웨어가 강제하는 한계를 가질 수 있고, 권한 모델 덕분에 strcpy() 같은 함수가 대상 버퍼나 자기 작업 공간이 아닌 메모리에 쓸 수 없게 만들 수 있었음. 언어와 OS는 호출된 함수가 호출자의 스택에 쓰지 못하게 하거나, 심지어 완전히 별도의 스택에서 실행되게 강제할 수도 있었음. 이건 시작에 불과함
    거의 40년이 지난 지금도 업계는 평탄한 메모리 모델과 단순한 사용자/감독자 권한 모델을 중심으로 OS와 프로그래밍 언어를 설계한 실수에서 회복하려고 애쓰고 있음. 386은 오늘날에도 흔하지 않은 OS 기능을 작성하기 위한 하드웨어 지원을 제공했음. 예를 들면 CHERI를 보면 됨

    • “포인터(능력, 즉 선택자)가 기준 주소뿐 아니라 하드웨어가 강제하는 한계를 가질 수 있다”고 해도, LDT에는 가능한 포인터가 8천 개, GDT에도 8천 개뿐임. x86의 세그먼트 모델은 능력 구현에 그리 적합하지 않음
    • grsecurity를 따라보지 않은 지는 오래됐지만, 세그먼트 레지스터가 아직도 쓰이고 있어도 놀랍지 않음. 예를 들면 PaX UDEREF 같은 경우임
      https://forums.grsecurity.net/viewtopic.php?f=7&t=3046
      https://pax.grsecurity.net/docs/PaXTeam-H2HC12-PaX-kernel-se...
    • 세그먼트 기반 보호 모드 전반은 이미 286에서 도입됐음. 386은 FS/GS를 추가하고 세그먼트를 32비트로 키운 정도임
  • 386SX가 얼마나 중요했는지 강조하고 싶음. 아버지가 내 PC를 원해서 친구에게 286 클론을 조립해 달라고 했는데, 그 친구가 대신 386SX를 줬음
    “286과 거의 같은 가격이지만, 지금 받는 건 분명히 32비트 CPU다”라고 했고, 맞는 말이었음. 그걸로 Win 3.11을 돌릴 수 있었음. 286 가격에 살 수 있는 32비트 CPU라 꽤 감당 가능했다니, 천재적인 제품이었음

  • 여기서 286도 어느 정도 인정받는 게 좋음. 286은 이전 세대 대비 클록당 명령 처리량이 훨씬 좋아서 꽤 과소평가된 칩이었고, 이 점이 386에 대한 주요 흠으로 이어짐
    기존 16비트 코드를 돌릴 때 386의 클록당 명령 처리량은 기본적으로 286과 같았고, 초기 클록도 12MHz라 꽤 심심했음. 클록이 본격적으로 올라가고 사람들이 32비트 기능을 쓰기 시작하기 전까지는 비싼 DOS/286 경쟁자 이상의 의미가 크지 않았음

  • 386이 출시된 지 얼마 안 됐을 때, 십대였던 내가 첫 컴퓨터를 샀음. 당시 시장에는 286과 386 PC가 모두 있었지만 386은 가격 프리미엄이 컸음
    그때는 차이를 잘 몰라서 286 시스템을 샀고, 몇 년 안에 차이를 알게 된 뒤 돈을 더 모아 386을 사지 않은 걸 크게 후회했음. 얼마 후 장난감 OS의 시스템 부트스트랩 같은 저수준 어셈블리를 쓰기 시작했지만, 32비트 보호 모드는 쓸 수 없었음. 게다가 어느 시점부터 386 전용 게임도 나오기 시작해서, 첫 486을 사기 전까지 꽤 소외감을 느꼈음

  • Intel은 x86 계열을 386 이후 Pentium Pro와 amd64까지 발전시켰는데, Motorola는 왜 68k를 그렇게 하지 않았는지 궁금함
    68k는 구식이 되었고 PowerPC로 대체되어야 했다는 식으로 전제처럼 다루는 논의를 본 적은 있지만, 추측처럼 보임. 기술적인 논거는 본 적이 없고, 68k는 286 이후의 x86보다 앞으로 끌고 가기 더 깔끔한 아키텍처처럼 보임

    • 68k를 쓰는 컴퓨터가 충분히 많이 팔리지 않아 칩 수요가 부족했고, 그래서 Intel과 가격 경쟁을 할 수 없었으며 대규모 연구개발 투자도 정당화하기 어려웠음. Intel에는 PC 호환 시장이 있었고, 그 덕분에 칩에 대한 거대한 수요가 있었음
    • 기술 문제가 아니라 Intel이 접근할 수 있었던 “돈더미”가 없었고, 동시에 고객들이 하위 호환성을 요구했다는 점이 문제였음
      Intel도 최소 두 번 i860이나 Itanic으로 옮기려 했지만 실패했음. 그래서 x86을 개선하는 쪽이 이기는 선택이 됐음
      https://news.ycombinator.com/item?id=37796469
    • 68k 프로세서 기반으로 IDE, VESA, PCI 시스템을 만들려는 상업적 시도가 있었냐고 하면, 어느 정도는 있었음. VME 버스가 있었음
      여러 업체 간에 동작하고 88k CPU에도 맞는 표준 기반 버스를 만들려는 시도였음. 엄청난 성공은 아니었지만 어느 정도 성공하긴 했음
  • “가장 중요했다”는 표현에는 약간 후대식 해석이 들어간 것처럼 들림. 8086/8088이 IBM PC를 통해 우연히 보편화되지 않았다면, 80286은커녕 80386도 아마 없었을 것임
    그렇다고 해도 386은 세상을 바꾼 공학적 성취였음. 더 정의롭고 공정한 타임라인에서는 68030이 세상을 장악했을 거라고 생각하지만, Intel이 해낸 일을 깎아내릴 수는 없음

    • 386은 그럴 수 있어도, 286은 IBM PC가 출시될 때쯤 이미 완성돼 있었거나 그 이전에 완성됐을 가능성이 큼
  • 386은 그 계열에서 요구 페이징 가상 메모리를 처음 지원했고, 덕분에 OS가 할 수 있는 일이 크게 열렸음. 개인적으로는 이게 386이 제공한 가장 중요한 기능이라고 봄
    내 두 번째 PC는 SCO UNIX를 돌리던 386이었음. 첫 PC는 CP/M을 돌리던 8080 기반 Heathkit H-8이었음

  • Bob Childs가 286 설계자 중 한 명이었고, 비공식적으로 286의 32비트 확장 아이디어를 약 6개월 동안 구상했다는 대목이 놀라움
    대체 어떻게 그런 일이 가능하지? 30년 동안 일하면서 며칠마다 뭔가 눈에 보이는 산출물을 내라고 목을 조르는 사람이 없는 직장은 한 번도 가져본 적이 없음