Linux/4004: 상업적 목적 없이 Intel 4004에서 Linux 부팅하기

 (dmitry.gr)
1P by GN⁺ | ★ favorite | 댓글 2개
  • 1971년의 4비트 Intel 4004만 CPU로 쓰는 실제 보드에서 Debian Linux가 부팅되어, 오래된 마이크로프로세서 한계와 소프트웨어 계층화의 극단을 보여줌
  • Linux는 4004에서 직접 실행되지 않고, 4004 어셈블리로 만든 MIPS R3000/DECstation 2100 에뮬레이터 위에서 부팅되며 디스크와 콘솔 일부는 하이퍼콜과 준가상화 드라이버로 단순화됨
  • 4KB ROM 한계, 4비트 연산, 논리 연산 부재, 얕은 호출 스택, 4002 RAM의 특이한 주소 지정 때문에 ROM 뱅킹, lookup table, status nibble, PSRAM 기반 가상 RAM 같은 우회가 필요했음
  • 최적화 후 실제 4004 740KHz 기준 Linux 부팅 예상 시간은 4.76일이며, 제작 보드는 790KHz로 오버클럭해 가상 MIPS가 약 74.73Hz로 동작함
  • 결과물은 벽에 걸 수 있는 레트로 아트 보드로 설계됐고, 40x2 VFD, 32개 PC LED, SD 카드, SPI PSRAM, UART를 갖추며 소스와 디스크 이미지는 비상업적 사용 조건으로 공개됨

실제 4004에서 Debian Linux 부팅

  • Linux/4004는 1971년 Intel 4004를 유일한 CPU로 쓰는 실제 보드에서 Debian Linux를 부팅한 프로젝트임
  • 4004는 세계 최초의 상업 생산 마이크로프로세서로 소개되며, 프로젝트에는 1970년대의 실제 Intel 4004 칩이 사용됨
  • 시연 영상은 지루함을 줄이기 위해 구간별로 가변 배속 처리됐고, 화면 속 시계와 달력은 정확함
  • 일정 배속으로 재생되는 원본 성격의 영상도 별도로 제공됨

왜 4004였나

  • 2012년에는 8비트 AVR 마이크로컨트롤러에서 Linux를 실행해 “가장 낮은 사양에서 Linux 실행” 기록을 세웠고, 이후 더 실용적인 LinuxCard 프로젝트도 진행됨
  • 2023년에 AVR 기반 기록 갱신 시도와 MOS 6510에서 Linux를 부팅하는 프로젝트가 등장하면서 더 낮은 수준의 CPU가 목표가 됨
  • 후보였던 Intel 8080과 8008보다 더 과거로 가기 위해 1971년의 Intel 4004가 선택됨
  • 4004는 4비트 칩이어서 8비트 CPU보다 낮은 기준을 명확히 세울 수 있음

Intel 4004의 제약

  • 4004는 4비트 단위로 동작하고, 대부분의 명령은 1바이트이며 8클럭 사이클에 실행됨
    • 일부 2바이트 명령은 16사이클이 필요함
    • FIN은 1바이트 명령이지만 16사이클이 걸리는 예외임
  • 명령어 집합에는 AND, OR, XOR 같은 논리 연산이 없고, 기본적으로 ADD와 SUB 중심임
  • carry flag는 SUB 입력에서는 borrow처럼, SUB 이후에는 not borrow처럼 동작하는 특이한 방식이며 실제 하드웨어에서 확인됨
  • 내부 레지스터는 4비트 16개이고, PC는 12비트이며, 하드웨어 return stack은 4단계임
    • 현재 top stack entry가 PC로 쓰이므로 실제 함수 중첩은 최대 3단계임
  • 인터럽트는 없고, TEST 핀을 조건 분기에서 폴링하는 방식이 외부 이벤트 처리에 가장 가까움

메모리와 I/O 구조

  • 4004는 메모리 명령 자체를 직접 처리하지 않고, 버스에 붙은 4001/4002/4289/4265/4308 같은 칩들이 명령을 디코드하고 실행함
  • 4001은 256바이트 mask ROM과 4비트 I/O 포트를 가진 ROM 칩이며, ROM 내용과 I/O 포트 구성은 제조 시 고정됨
  • 4002는 320비트 DRAM, refresh 회로, 4비트 output-only 포트를 가진 RAM 칩임
    • RAM bank 하나는 4개의 4002로 구성될 수 있음
    • 각 RAM bank에는 직접 주소 지정 가능한 256 nibble과 별도로 접근하는 64개의 status nibble이 있음
  • 4289는 4008과 4009의 기능을 합친 ROM 컨트롤러로, 4004를 5V EEPROM/EPROM과 비교적 쉽게 연결할 수 있게 함
  • 메모리 접근에는 bank 선택, 주소를 레지스터 쌍에 로드, SRC로 버스에 주소 전송, RDM/WRM 실행 같은 다단계 절차가 필요함
    • status nibble은 자주 쓰는 데이터를 빠르게 접근하는 데 유용했고, MIPS 에뮬레이터 속도를 약 30% 높이는 데 기여함

개발 보드와 에뮬레이터 준비

  • 초기 검증용 개발 보드는 4201 clock generator, 4004 CPU, 4002-1 RAM, 4289 ROM controller, ROM 역할의 ATMEGA48로 구성됨
  • 전원은 5V에서 시작하고, 절연형 5V-to-10V boost converter의 양극을 접지해 -10V 전원을 만들어 MCS-04 칩에 공급함
  • 첫 4004 프로그램은 4002 output pin 0에 연결된 LED를 깜박이는 코드였고, 전류 제한을 올린 뒤 동작함
  • 실제 보드를 만들기 전에 u4004라는 4004 에뮬레이터를 작성함
    • 4004 코어뿐 아니라 가상 SD 카드, SPI UART, VFD, 4002 배치, PC LED까지 에뮬레이션함
    • 실제 하드웨어에서 디버깅하기 어려운 SPI 핀 상태와 주변장치 동작을 먼저 검증하는 용도였음

Linux를 직접 실행하지 않고 MIPS를 에뮬레이션

  • Linux는 4004에서 직접 실행될 수 없음
    • 4004 대상 C 컴파일러가 없고, 아키텍처 제약상 Linux 커널을 직접 올리기 어렵다고 판단됨
    • 호출 중첩, ROM/RAM 주소 공간, 4비트 연산 한계가 직접 실행을 막음
  • 대신 4004 위에서 MIPS R3000 에뮬레이터를 작성하고, 그 위에서 DECstation 2100용 Linux를 부팅함
  • MIPS는 다른 후보보다 4004 코드 공간 안에서 에뮬레이션하기 쉬워 선택됨
    • ARM은 임의 shift operand가 많음
    • RISC-V는 주소 지정 방식 때문에 느릴 것으로 판단됨
    • x86은 명령 디코딩만으로도 4KB를 넘을 수 있음
    • PPC는 너무 복잡함
  • 초기 목표는 4004가 기본적으로 주소 지정 가능한 4KB ROM 안에 전체 에뮬레이터를 넣는 것이었음

MIPS 에뮬레이터 구현상의 우회

  • MIPS 명령 디코딩만으로도 상당한 ROM 공간이 소모됨
    • top-level opcode 64개 dispatch table은 128바이트가 필요함
    • 추가 sub-table까지 포함하면 주요 디코딩에 359바이트가 필요했음
  • MIPS의 32개 32비트 레지스터는 1024비트, 즉 4004 관점에서 256 nibble이며 RAM bank 하나를 차지함
  • MIPS TLB는 원래 64개 entry지만 Linux가 정확히 64개를 요구하지 않아 16개 entry로 줄임
    • TLB entry 수는 4, 8, 12, 16개 구성도 가능하도록 설계됨
  • 4004에는 논리 연산이 없어서 AND/OR/XOR/NOR는 덧셈과 carry, shift, 루프로 구현됨
    • 나중에는 ROM 공간이 늘어난 뒤 256-entry lookup table로 최적화됨
  • shift도 4004의 1비트 carry 경유 회전 명령만으로 구현해야 했고, 이후 nibble 단위 복사와 최대 3회 bit shift로 개선됨
  • MIPS의 $zero 레지스터 처리는 4004의 circular return stack 특성을 이용해 ROM 공간을 절약함
    • 목적지가 $zero인 경우 return하지 않고 다음 명령 처리로 이동하는 방식으로 callsite당 3바이트와 3사이클을 줄임

ROM 뱅킹과 성능 개선

  • 4KB ROM만으로는 SD 카드, PSRAM, VFD, UART 등을 다루는 코드까지 넣을 수 없어 8KB ROM을 두 bank로 나누어 사용함
  • ROM bank 전환은 4002 output pin으로 제어하고, bank 간 call/return을 위해 veneer를 배치함
  • ROM 공간이 늘어난 뒤 성능 최적화가 가능해짐
    • AND/OR/XOR는 각각 256-entry lookup table로 구현됨
    • nibble 곱셈 lookup table을 사용해 multiplication은 이전의 bit 단위 구현보다 8배 빨라짐
  • 논리 연산 lookup table은 4004의 JIN이 ROM page 마지막에 있을 때 다음 page 기준으로 jump한다는 특성을 활용함
  • multiplication table은 FIN으로 ROM의 byte 데이터를 읽는 방식과 0 entry 처리 회피를 조합해 구현됨

최종 하드웨어 구성

  • 최종 보드는 1970년대 느낌의 스루홀 중심 아트 보드로 설계됨
    • 두꺼운 직각 trace, via 없음, 벽걸이 구멍, VFD 표시 장치가 포함됨
  • 주요 구성 요소는 다음과 같음
    • 4004 또는 4040 CPU
    • 4201 clock generator
    • 4002 RAM 칩들
    • 4289 ROM controller
    • EEPROM
    • SPI PSRAM 1~2개
    • SD 카드 슬롯
    • SC16IS741A SPI UART
    • 40x2 VFD
    • 32개 PC 표시 LED
  • SPI PSRAM은 가상 MIPS RAM으로 사용됨
    • 첫 번째 PSRAM은 커널을 연속적으로 적재해야 하므로 최소 4MB가 필요함
    • 두 번째 PSRAM은 비워두거나 128KB 이상 임의 크기로 장착 가능함
  • VFD는 Futaba M402SD10FJ가 사용됐고, Noritake CU40025-UW6J가 호환된다고 전달받음
  • UART는 스루홀 SPI UART 후보였던 MAX3100의 흐름 제어 제약 때문에 SC16IS741A 표면실장 부품으로 선택됨

전원과 레벨 시프팅

  • MCS-04 부품들은 -15V 계열의 특이한 전압과 inverted logic을 사용함
    • 시스템적으로는 -10V와 +5V 공급으로 생각하는 편이 단순함
  • 보드는 USB-C edge connector로 +5V를 받고, +3.3V와 -10V도 생성함
  • +3.3V step-down regulator는 LM2574 기반으로 구성됨
  • -10V 전원은 첫 revision의 MAX764가 충분한 전류를 공급하지 못해 MAX774와 외부 FET, 큰 diode, 큰 inductor 구성으로 변경됨
    • 최종적으로 -10V에서 700mA 이상을 공급하고 ripple은 200mV 미만임
  • 4002 output을 3.3V domain으로 변환하는 레벨 시프팅은 어려웠고, 10K pulldown, 2.7K resistor, TVS clamp, 저항 분압을 조합한 방식으로 해결됨

디버깅 도구와 실제 결함

  • 4004에는 내장 디버깅 기능이 없기 때문에 Saleae Logic으로 MCS-04 bus를 장시간 캡처함
  • MCS-04 bus decoder를 작성해 bus state, ROM address, ROM read value, disassembly, RAM/I/O read/write 값을 분석함
    • 이후 Saleae에 기여되어 일반 Saleae software에 포함됨
  • revision 1.1 보드에서는 출력 문자가 드물게 깨지는 문제가 있었음
    • 예를 들어 i가 h로, C가 B로 보이는 식으로 하위 bit가 사라짐
  • 분석 결과 kernel memcpy() 중 emulated $t1이 저장된 4002 칩에서 특정 nibble의 bottom bit가 가끔 1에서 0으로 떨어지는 결함이 확인됨
  • 해당 4002를 교체한 뒤 텍스트 출력이 정상화됨

부팅 경로

  • firmware는 먼저 세 번째 RAM bank의 메모리 칩 수를 probe해 TLB entry 수를 파악함
  • 이후 VFD, UART, SD 카드를 초기화함
    • SD 카드 초기화 실패 시 "Failed to init SD card. Halting here and now!"를 표시함
    • 이 문자열은 firmware 전체에서 유일한 문자열임
  • firmware에는 가상 ROM을 두지 않고, SD 카드 첫 sector를 RAM의 0x80000000에 로드한 뒤 점프함
  • 첫 sector의 446바이트 loader는 partition table에서 type 0xBB partition을 찾아 0x80001000에 읽고 점프함
  • 두 번째 loader는 약 14KB 크기이며 C로 작성됨
    • active partition을 FAT12/16/32로 mount함
    • vmlinux를 ELF로 파싱해 RAM에 로드하고 entrypoint로 점프함
    • machine type, magic value, RAM mapping과 early console printing용 callback table을 전달함

디스크와 SD 카드 접근

  • 디스크 접근은 LinuxCard 프로젝트와 같은 PVD 준가상화 디스크 드라이버를 사용함
  • 4004 assembly로 SII SCSI chip과 SCSI disk를 에뮬레이션하는 대신, sector read/write hypercall이 가상 MIPS 입장에서 DMA처럼 동작함
  • Linux/4004 보드의 전체 RAM은 status nibble까지 포함하면 440바이트, 제외하면 352바이트임
    • MIPS register state와 TLB가 각각 큰 비중을 차지해 SD 카드의 512바이트 sector buffer를 둘 공간이 없음
  • SD sector 데이터는 4004 RAM에 담지 않고, SD 카드와 PSRAM의 별도 SPI bus를 이용해 직접 PSRAM으로 읽거나 PSRAM에서 SD로 씀
  • SD sector 하나를 읽거나 쓰는 데는 약 1초가 조금 넘게 걸림
  • SD spec의 ACMD41 초기화 timing 요구사항은 비트뱅잉 SPI로 맞출 수 없었지만, 테스트한 SD 카드들은 5KHz 및 200ms 이상 간격에서도 초기화됐음

실행 속도와 최적화 결과

  • 실제 SD 카드와 SPI PSRAM을 에뮬레이션한 뒤 초기 예상 부팅 시간은 740KHz 4004 기준 8.9일이었음
  • 주요 최적화 결과는 다음과 같음
    • 논리 연산과 multiplication lookup table로 8.4일
    • PSRAM nibble 송수신 루프 펼치기로 7.25일
    • specialized memory copy와 루프 펼치기로 6.63일
    • 현재 명령어 저장 영역 제거와 liveness 추적으로 6.50일
    • shift 개선으로 6.19일
    • PSRAM address sending 루프 펼치기로 6.01일
    • Linux kernel config 축소와 dummy console 1x1 설정, tiny init 사용으로 5.33일
    • 2TB 이상 block device 지원 제거와 ext4 huge_files feature 비활성화로 4.81일
    • instruction fetch 전용 fast path로 4.76일
  • 4.76일 부팅은 740KHz 4004 기준 약 70Hz MIPS machine에 해당함
  • 제작 보드는 4201을 divide-by-7 모드로 쓰고 5.5296MHz crystal을 사용해 790KHz로 오버클럭됨
  • Linux/4004 보드의 4004 instruction mix는 16-cycle 명령 8.8%, 8-cycle 명령 91.2%이며, effective speed는 90,640 instructions/s임
  • 가상 timer interrupt는 16Hz이고 65,536 virtual instruction마다 IRQ를 전달해 가상 CPU는 1.05MHz로 인식함
    • 실제 emulated MIPS guest는 740KHz에서 약 70Hz, 790KHz에서 약 74.73Hz임
    • 시간은 14,030배 늘어나며 가상 1초가 현실 약 3시간 54분에 해당함

Linux 구성과 사용 경험

  • Linux kernel은 불필요한 subsystem과 filesystem, TCP/IP 등 필요 없는 설정을 제거해 약 2.5MB로 줄임
  • init=/bin/sh만 쓰면 session, $PATH, /proc, /sys 등이 없는 상태가 되므로 tiny init인 /sbin/uMIPSinit을 작성함
    • /proc와 /sys를 mount함
    • hostname과 $PATH를 설정함
    • sh가 종료될 때마다 다시 실행함
  • 4.5MB RAM, 예를 들어 4MB chip + 512KB chip만으로도 swap 없이 shell prompt까지 부팅 가능함
  • swap을 켜면 장치 자체에서 kernel source를 빌드할 수 있음
    • kernel source build는 수년이 걸릴 것으로 예상됨
    • ext4 journal 덕분에 전원이 끊겨도 재부팅 후 filesystem을 복구하고 compilation을 다시 시작하는 계획임

아트 보드로서의 목표

  • 이 프로젝트는 처음부터 부분적으로 예술적 목표를 가짐
  • 보드는 벽에 걸 수 있도록 설계됐고, VFD와 retro-style PCB layout, PC LED를 갖춤
  • VFD와 serial port에 Mandelbrot set을 text mode로 그리는 프로그램이 포함됨
    • floating point 버전 /root/mandelbrot는 Linux가 부동소수점 연산을 에뮬레이션해야 하므로 13행 x 40열 이미지를 그리는 데 약 30일이 걸림
    • integer-only 버전 /root/mandelbrot_nofp는 9시간 이내에 완료됨

부품 비용과 재현성

  • 다른 사람이 재현할 수 있게 하는 것이 중요한 목표였기 때문에 구하기 어려운 4265는 피함
  • 4201은 대체 clock 회로보다 간단하고, 4289는 4008+4009 조합보다 구하기 쉬워 선택됨
  • 보드는 4004 대신 4040도 장착할 수 있게 설계됐고, 4040의 추가 기능은 사용하지 않아 4004 호환성을 유지함
  • TLB용 4002 칩은 1, 2, 3, 4개만 장착해 각각 4, 8, 12, 16 entry TLB로 쓸 수 있음
    • TLB entry 수가 적으면 성능이 떨어짐
    • 해당 bank는 PC display LED의 high 16 bits도 담당하므로 일부만 장착하면 일부 LED가 동작하지 않음
  • 1970년대 부품은 비쌈
    • 4004는 약 $250
    • 4040은 약 $60
    • 4201은 약 $50
    • 4002-1은 약 $7
    • 4002-2는 약 $25
    • 4289는 약 $70
  • 현대 부품은 상대적으로 저렴하며, SPI VFD는 구하기 어려울 수 있지만 eBay에서 $15에 구한 사례가 있음
  • VFD를 장착하지 않고 serial port만으로 상호작용하는 구성도 지원됨

영상 제작 과정

  • 실제 부팅 장면은 약 9일 동안 사진을 촬영해 영상으로 만들었음
  • 1920x1080 사진을 2초마다 찍으면 시간당 약 1.76GB가 생성되고, 9일 촬영은 약 379GB와 약 38만8천 개 파일이 됨
  • Android 기기들은 장시간 촬영 중 hang 또는 과열 문제가 있었고, iPhone SE3는 촬영 자체는 안정적이었지만 저장공간과 사진 offload 문제가 있었음
  • 최종적으로 512GB iPhone 12 Pro Max를 사용해 전체를 연속 촬영하고, Linux에서 ifuse로 mount한 뒤 cp -Rvf로 약 40만 개 파일을 10시간 넘게 복사함
  • 최종 영상은 ffmpeg 명령들로 제작됐고, 지루한 구간은 가변 배속 처리됨
    • 재생 속도는 5FPS, 즉 10x realtime부터 960FPS, 즉 1920x realtime까지 변함
    • 별도 무편집 버전은 0.5FPS capture, 60FPS playback으로 120x realtime 속도임

공개 자료와 라이선스

  • SD 카드용 disk image는 별도 다운로드로 제공됨
  • main download에는 다음이 포함됨
    • Saleae software용 MCS-04 bus analyzer
    • i4004 DECstation 2100 emulator source
    • MIPS MBR과 second-stage bootloader source
    • kernel config와 version info
    • Linux/4004 보드용 u4004 emulator source
  • 라이선스는 비상업적 사용 무료이며, 상업적 사용은 별도 라이선스가 필요함
  • 어떤 사용이든 source와 binary form에서 원 제작자를 credit해야 함

함께 보면 좋은 글 β

y15un   [-]

원글 저자가 이번에 데프콘에서 배지 관련으로 무대에서 끌려나간 그 양반이군요. 누구 편을 들지는 않겠습니다만 그래도 실력은 진짜 대단하네요.

답변달기
GN⁺   [-]
Hacker News 의견들

  • 와, 15MHz m68030, 16비트 메모리 버스, RAM 10MB에서 현대 NetBSD가 느리다고 생각했는데 이건 정말 미쳤다
    80년대 말~90년대 초에 컴퓨터가 영구 저장장치, 열린 주소 공간, MMU를 갖추기 시작하면서 사실상 현대 컴퓨팅에 도달했다는 점을 잘 보여줌
    Amiga 3000이나 i80486 컴퓨터도 현대 컴퓨터와 같은 것들을 실행할 수 있고, 지금은 훨씬 빠르게 실행하거나 당시 없던 GPU 같은 것도 있지만 기능적으로는 큰 차이가 없음
    Dmitry가 기능적이라는 말을 얼마나 느슨하게 정의할 수 있는지 보여주는 게 좋다

    • 미국에서도 그랬는지는 모르겠지만, 70~80년대 소련에서는 서신 체스가 아주 인기 있었다
      실제 우편으로 수를 주고받았고, 한 판이 몇 달이나 몇 년씩 걸리기도 했음
      답장이 올 때쯤엔 원래 전략을 잊어버릴 수 있어서 체스에 또 다른 난도가 추가됐는데, 이 프로젝트는 사실상 서신 Linux임
      명령 출력이 나올 때쯤엔 왜 그 명령을 실행했는지 잊어버릴 수 있음
    • 15MHz m68030, 16비트 메모리 버스, RAM 10MB라면 혹시 Mac LC II인가? :)
      80년대 말~90년대 초가 아니라 사실 1960년대 말쯤이면 이미 가능했음
      Linux를 IBM Model 67 [1]에 포팅하는 것도 가능할 것 같고, GCC가 이미 그 명령어 집합을 대상으로 할 수 있으니 쉬울 수도 있음
      MMU도 충분하고, 빠른 코어 메모리 최대 2MB라는 제약이 빡빡하긴 하겠지만 그 68030 머신과 비슷한 급으로 조금 더 느린 정도일 듯함
      완전 가상화와 하드웨어가 강제하는 메모리·입출력 경계도 초기에 발명됐지만, 이런 기능이 미니컴퓨터와 마이크로컴퓨터로 내려오는 데 시간이 걸렸고, 대중적인 소프트웨어가 활용하기까지는 훨씬 더 오래 걸렸음
      [1] https://en.wikipedia.org/wiki/IBM_System/360_Model_67
    • 이건 기본적으로 튜링 완전성의 개념임
      어떤 튜링 완전 시스템이든 무엇이든 실행할 수 있고, 아주 느릴 수는 있어도 실행은 됨
      시간만 있으면 ChatGPT도 4004에서 돌릴 수 있음
    • 멀티코어는 꽤 큰 기능적 차이임
      바퀴에 자동차를 붙이면 바퀴가 세 개 더 생기는 것과 비슷함

  • Hackaday Supercon 2002의 참가자 배지(https://hackaday.com/2022/10/12/the-2022-supercon-badge-is-a...)는 가상의 4비트 CPU와, 명령을 직접 입력하고 실행·단계 실행할 수 있는 제어판을 구현했음
    제어판에 메모리 한 페이지를 비트 단위로 볼 수 있는 화면이 있어서, 그 위에 우주 슈팅 게임을 구현하는 게 정말 재미있었음
    Voya4 아키텍처를 4004와 비교하는 것도 흥미로웠고, 비슷한 절충도 있었지만 Voya4는 50년치 CPU 명령어 집합 경험의 이점을 갖고 있음
    다만 dimitygr의 방식은 그 배지에서는 통하지 않는데, CPU 에뮬레이터를 구현하는 PIC24 안에 메모리와 RAM이 모두 내장되어 있기 때문임
    참고로 4비트 CPU는 아직도 만들어지고 쓰임. 대량 생산되는 많은 적외선 리모컨이 4비트 MCU로 프로그래밍됨. 데이터시트는 https://www.emmicroelectronic.com/sites/default/files/produc...를 보면 됨

    • 2022년임

  • 성능이 부족한 기계에서 뭔가 돌릴 수 있냐는 질문을 받으면 AVR 예시를 자주 들었는데, 이제 새로 링크할 예시가 생겼다
    주파수와 소비전력을 보면 RF를 얼마나 뿜어내는지, SDR의 워터폴에서 감지하고 해독할 수 있는지도 궁금함
    아직 읽는 중이지만, 이 시점 기준으로는 “soubroutine”이라는 단어가 보이는데 오타인 듯함

  • 와, 이건 싸게 끝난 프로젝트가 아니었겠다. eBay 수집가들 덕분임
    그리고 아마 내가 VFD 대신 LCD를 택했을 유일한 상황일 듯함
    몇 년짜리 컴파일을 돌린다면 끝날 때쯤 VFD는 번인으로 난리가 났을 것 같음

    • 개인적으로는 명예 박사를 받을 만한 프로젝트라고 봄
      안타깝게도 대학 교직원들은 HN을 그리 많이 읽지 않는 듯함

  • 와, 대단하다
    높은 PC 비트를 보면 지금 무엇이 실행 중인지 보임
    추신: 그래도 인터넷 너머 서버의 형편없는 IPMI에서 가상 ISO로 커널 로드하는 것보다는 빠름 ;D

    • 부팅하는 동안 LED를 보면서 vmlinux에 nm을 돌리면 커널 함수와 쉽게 매핑할 수 있음
      사용자 공간에 들어간 뒤에는 메인 바이너리(0x01000000보다 훨씬 아래)와 공유 라이브러리(0x77000000 근처의 높은 주소에 로드됨)도 구분할 수 있음
    • 인터넷 너머 서버의 형편없는 IPMI에서 가상 ISO로 커널을 로드한다는 말이, Raspberry Pi에서 돌아가는 NFS 호스팅 ISO로 Dell M1000e 블레이드 서버를 부팅하려던 기억을 떠올리게 함
      부팅도 실행도 고통스러울 만큼 느렸음

  • 정말 흥미로운 글이었다
    4004에 대해 조금 읽어봐서 이상한 칩이라는 건 알고 있었지만, 난해함의 정도가 상상을 넘음
    이제 같은 트랜지스터 수로 CPU를 만들면 얼마나 잘 만들 수 있을지 보고 싶어졌다
    6502보다 그렇게 많이 적은 수는 아니고, 8비트라면 프로그래밍이 훨씬 쉬워질 것 같음

    • 트랜지스터로 만들면 내 MIPS 에뮬레이터를 거기에 포팅하겠음 :)

  • 영상 촬영에 9일이 걸렸고, 에뮬레이션 1초당 4시간이 들었음
    그리고 왜 Windows 95를 쓰는지도 궁금함

    • Windows 2000임
      영상용으로 실제 직렬 포트가 있는, USB가 아닌 노트북이 필요했음
      이 노트북이 조건에 맞았고 eBay에서 20달러였음
      개인적으로 Windows 2000이 가장 예쁜 Windows라서 데모 영상용으로 설치했음
    • 사소한 지적이라 미안하지만, 영상 속 노트북은 Windows 2000처럼 보임

  • 정말 멋지다
    이 프로젝트 대부분을 이해할 수 있을 만큼 지식이 늘었으면 좋겠지만, 지금은 내 제한적인 컴퓨터과학 실력으로는 너무 어려웠음
    그래도 완전히 이해할 수 있었던 하이라이트는 “Section 14.b & 14.c - Getting the data...”였음
    고작 파일 40만 개, 4년 동안 하루 약 275장 사진이면 충분했음
    처리·저장·네트워크 성능이 이렇게 넘치는데도 가장 많이 쓰이는 듯한 미디어 동기화 앱들이 멈추거나 느리게 동기화되고, AirDrop은 실패하며, ‘전체 선택’ UI 기능도 없는 시대라니 정말 이상한 시대를 살고 있음 :)

    • Dmitry가 사진을 찍는 즉시 PC로 계속 복사하도록 MobiusSync나 Syncthing 같은 동기화 도구를 고려했는지 궁금함

  • 이런 일에는 노벨상 같은 게 필요함

    • 가장 가까운 건 아마 Ig Nobel Prize일 듯함: https://en.wikipedia.org/wiki/Ig_Nobel_Prize
    • 컴퓨팅 분야에는 그에 해당하는 Turing Award가 있음
      컴퓨터과학의 기이하고 특이한 응용에 대한 인정 부문을 추가할 수도 있겠음

  • “Why MIPS?” 섹션에서 “일부는 형편없는 주소 지정 방식 때문에 느릴 수밖에 없다(RISCV)”고 했는데, RISC-V 주소 지정 방식에 뭐가 문제임?

    • 실제로는 주소 지정 방식보다는 명령어 형식 문제에 가까움
      RISC-V의 일부 명령어에서는 즉시값 비트가 연속적으로 저장되지 않음
      MIPS 명령어에서는 즉시 덧셈, 상수 로드, 분기 등의 값 비트가 항상 순서대로 저장됨
      RISC-V에서는 비트가 가끔 뒤섞여 있음
      예를 들어 무조건 분기에서 목적지 오프셋 비트가 bit 19, bits 9-0, bit 10, bits 18-11 순서로 저장됨
      하드웨어에서는 배선만 올바르게 연결하면 되니 재배열 비용이 사실상 없지만, 소프트웨어에서는 이를 바로잡기 위해 많은 비트 조작이 필요함
      RISC-V가 이렇게 하는 이유는 하드웨어 설계를 단순화하기 위해서임
    • 극도로 성능이 낮은 하드웨어에서 에뮬레이션하려는 게 아니라면 아마 별문제 없을 것임
답변달기