▲

집에서 만든 CPU와 C 컴파일러로 Xv6 유닉스 계열 OS를 구동한 경험

 (fuel.edby.coffee)
4P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 대학시절 프로젝트에서, 직접 설계한 RISC ISA 기반 CPU와 자체 제작한 C 컴파일러를 이용해 Xv6 운영체제 포팅을 시도한 경험 공유
  • 프로젝트는 CPU 설계, C 컴파일러(Ucc) 개발, Xv6 이식 등 모든 요소를 직접 만드는 방식으로 진행
  • 팀은 OS 동작을 위해 인터럽트, 가상 메모리, 캐시 등 핵심 하드웨어·소프트웨어 기능 설계에 도전함
  • Xv6 이식 과정에서 이식성 문제, 디버깅의 어려움, 캐시 버그 등 다양한 난관에 직면했으나 자체적으로 해결함
  • SL, Minesweeper, 2048 등 인터랙티브 애플리케이션과 ray-tracing 프로그램 구동까지 성공하여 교육적·기술적으로 큰 성취를 경험함

프로젝트 개요

  • 본 프로젝트는 Tokyo University 정보과학과의 대표적인 실험 과제로, 학생들이 중앙처리장치(CPU)와 하드웨어 설계, 컴파일러 제작, 애플리케이션 실행 경험을 쌓는 데 중점을 둠
  • 프로젝트의 목표는 자체 설계한 CPU의 ISA로 FPGA에 직접 구현하고, 이를 위한 C 툴체인(Ucc) 제작, 그리고 XO6와 같은 운영체제 포팅으로 확대함
  • 실험 과정의 대부분은 자기주도 학습으로 진행됨

CPU 실험과 과제

  • 4~5인 팀이 각자 새로운 CPU 아키텍처 설계 및 FPGA 구현, 그리고 해당 아키텍처용 컴파일러 개발에 참여함
  • OCaml 서브셋 컴파일러 제작 후 레이 트레이싱 프로그램 실행까지가 필수 평가 항목임
  • 추가적으로 시간 여유가 생기면 고유의 도전과제를 설정할 수 있으며, 일부 학생은 CPU 고속화, 멀티코어 개발, 음악/게임 실행 등 확장 실험을 진행함
  • Group 6 팀은 특히 운영체제 포팅을 목표로, 여기서부터 새로운 공동팀(Group X)이 결성됨

Xv6 OS와 이식 도전

  • 이식 대상으로 MIT에서 교육용으로 개발한 Xv6(Unix v6 기반, x86 용) 선택
  • Xv6는 간단한 유닉스 기반(OS)지만 실제 하드웨어 실행을 위한 C89 컴파일러, 특수 인터럽트, 가상 주소 지원, 포터블성 부족 등 다양한 문제가 존재함
  • Xv6는 C 언어 기준 char 1바이트, int 4바이트 등 x86 특성을 전제로 만들어져 있어, 이식 시 많은 문제가 발생함

컴파일러 및 툴체인 개발(Ucc)

  • 기존 실험에서는 OCaml 컴파일러 개발이 표준이었으나, Xv6 구동을 위해서는 C89 컴파일러가 필요해 직접 개발을 결정함
  • 팀원 중 한 명의 C 컴파일러 프로토타입을 기반으로, 새로운 툴체인을 자체 구축(Ucc)
  • 컴파일러 뿐 아니라 Primitive Linker 및 디버그 도구 등도 직접 설계함

CPU 및 시뮬레이터 설계

  • 하드웨어 서술 언어(HDL, 예: Verilog / VHDL)로 CPU 회로 설계 후 Vivado/Quartus 등 논리합성 과정으로 실물 FPGA에 구현함
  • 반복적인 논리합성 과정은 시간이 매우 오래 걸려 실질적으로 많은 대기 시간이 수반됨
  • CPU 기본 기능 이후 인터럽트, MMU, TLB 등 OS 구동에 필요한 하드웨어 지원도 별도 설계
  • GAIA라는 이름의 CPU로 완성됨
  • 시뮬레이터에는 실제 인터럽트, 가상 주소 변환, 디버깅 툴 추가됨

이식 과정의 문제와 해결

  • Xv6의 포팅성 부족으로, CPU 및 컴파일러 사양에 따라 비정상적인 동작 발생
    • 예시: char와 int가 32비트로 정의되면서 포인터 연산 및 스택 구조가 깨지는 문제 등
    • 컴파일러 Ucc에서 char를 8비트로 맞추도록 개선
  • 인터럽트 처리는 고난도 영역으로, 자체 시뮬레이터에 분해기, 상태 덤프 등 디버깅 도구가 추가됨
  • 캐시 알리아스 이슈는 GAIA가 가상 주소로 캐시 인덱스 삼으면서 발생, Page Coloring 기법 도입으로 해결

최종 결과: OS 및 앱 실행

  • 3월 1일 최종적으로 Xv6를 완전히 시뮬레이터와 실 CPU(하드웨어)에서 실행하는 데 성공함
  • 자체 미니 curses, SL 명령, Minesweeper, 2048 등 인터랙티브 앱 구동 성공
    • 특히 2048은 논 캔터노컬(non-canonical) 입력 지원 설계 추가
    • Xv6 수정을 통해 POSIX 스타일의 ioctl, termios 등에 해당하는 기능까지 추가
    • 소형 assembler, mini vi 등도 구현, 실질적 ‘실시간 프로그래밍 환경’ 실현
  • 레이 트레이싱 프로그램도 운영체제 위에서 동작시켜 원래의 실험 목적 이상의 결과 달성

프로젝트의 의의와 후속 사례

  • 본 실험 이후 여러 세대 학생들이 직접 CPU와 OS를 만들어 다양한 실험을 지속적으로 수행함
    • 예를 들어 RISC-V ISA 채택, 자체 OS, Linux 구동 등으로 확장
  • 실습을 통해 직접 하드웨어/소프트웨어 전 스택을 경험하며 알고리듬, 하드웨어-소프트웨어 통합, 저수준 구조에 대한 실질적 이해 증진
  • “바퀴 재발명”이 비효율적이라는 비판도 있으나, 실제로 만들어 보며 배우는 학습효과와 재미는 매우 큼

실제 체험 및 소스 코드

결론

  • “직접 만드는 것만큼 배우는 것은 없다”는 교훈과 함께, 하드웨어-소프트웨어 통합 경험의 중요성을 강조함
  • 후속 학생들도 계속해서 새로운 목표에 도전하며, 미래엔 자체 ISA상에서 Linux나 VM이 구동될 수 있기를 기대함
  • 프로젝트 참여 멤버들의 이름을 끝으로 이야기 마무리
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 예전에 대학 시절 세 명이서 3주간 진행한 그룹 프로젝트 이야기가 생각남. 여러 주제 중 아주 기초적인 운영체제 직접 만들기 등이 있었는데, 교수님들께 Raspberry Pi에 MINIX3를 포팅해도 되는지 물어서 허락받음(MINIX3가 이미 BeagleBoard용 ARM 포트가 있어서 가능할 것 같았음).<br>예상보다 훨씬 난이도가 높았고, 상상도 못했던 기술적 문제들이 쏟아짐. 특히 Raspberry Pi 3이 supervisor 모드 대신 hypervisor 모드로 부팅되는 바람에 고생했고, QEMU의 Raspberry Pi 에뮬레이션 정확도가 너무 형편없어서 os 개발에는 거의 쓸모가 없었음. 해결책을 찾느라 저수준 하드웨어 디버깅을 일주일이나 붙잡음. <br>결국 UART, GPIO, 프레임버퍼 드라이버가 포함된 동작하는 포트를 만들었고, Raspberry Pi 2와 3에서 구동 성공. 실제 하드웨어로 발표 진행, 쉘 스크립트로 램디스크 이미지 출력, GPIO 핀을 모니터링하여 앞뒤 슬라이드 넘기도록 했고, 칼로 핀을 쇼트시켜 직접 조작함. originality 면에서 압도적으로 멋진 발표였고, 그 SD카드 이미지를 아직도 가지고 있을 것 같음

    • 멋진 경험 같음<br>MINIX3를 Raspberry Pi에 포팅하자고 한 순간, 교수님들이 실패를 예상했을 수도 있을 것 같음<br>QEMU의 Raspberry Pi 에뮬레이션 정확도가 별로일 때, 나는 QEMU에서 먼저 OS가 동작하게 만든 후 하드웨어에서 운에 맡기는 전략을 썼음. 그래도 괜찮았음<br>실제 Raspberry Pi에서 디버깅은 어떻게 했는지 궁금함

    • GPIO 쇼트시킬 때 칼을 사용했다고 들으니 ATX 메인보드에서 전원 스위치 없이 부팅하려고 두 전원 핀을 쇼트시킨 경험이 떠오름<br>그래도 너의 셋업이 훨씬 멋짐. 잘했음

  • SFU에서 25~30년 전에 비슷한 일을 했었음. OS와 컴파일러를 올리는 건 안 했고 팀 프로젝트도 아니었음<br>이런 실험에 흥미가 있다면, 가이드와 접근성 높은 툴링이 있는 Turing Complete 추천. 몇 개의 게이트에서 진짜 컴퓨터까지 만들어갈 수 있음. 커뮤니티와 컴포넌트도 공유 가능, RiscV 코어도 있음. 진짜 재미있으니 Steam에서 해보는 것 추천함<br>Turing Complete Steam 링크

    • 이거 보니까 예전에 재미있게 했던 nand2tetris의 게임 버전 같음. 이것도 해볼 만한 추천임

  • 이 글 보니 왠지 비슷한 학술(?) 프로젝트가 떠오름. 최소한 커스텀 C 컴파일러와 커스텀 OS가 있었던 것으로 기억함. 이름은 정확히 기억 안 남

  • 예전에 올라온 관련 토픽 참고 이전 글 링크

  • 직접 CPU + 컴파일러 + OS를 만들어갈 때는 밑에 깔린 플랫폼이 아예 없음. 내가 곧 플랫폼임.<br>버그가 곧 시스템의 법칙임. 보통은 남이 만든 추상화 레이어에서 디버깅하는데, 여기선 그 규칙조차 내가 직접 정의함. OP는 자기만의 규칙을 직접 디버깅한 셈임

  • 진짜 인상적임. 로우엔드 영역 작업은 보통 지루하고 시간도 많이 들고, 특히 디버거 같은 필수 도구가 없으면 더더욱 힘듦

    • 스코프로 이상한 kprintf 디버깅해본 경험이 없다면 아직 진정한 로우레벨 맛을 못 본 것임

  • Magic-1과 BMOW도 예전에 유사한 일을 했었음<br>자세한 내용은 homebrewcpu.com 참고<br>직접 CPU 만든 사이트 리스트는 homebrewcpuring.org 참고

  • 이제는 FPGA에 구현하는 대신 반도체 연구실로 달려가서 직접 CPU를 제작해달라고 해야 할 시점임

답변달기