개인 개발자가 만든 가상 머신 'ok'는 이름 그대로 매우 단순하다. 명령어 평가와 'data', 'return'이라는 두 개의 스택만 제공하며, 기본적인 계산을 수행할 뿐이다. 화면에 무언가를 출력하거나 마우스·키보드로 입력을 받는 기능은 아예 없다. 그런 입출력을 쓰려면 해당 장치를 메모리에 '매핑(map)'해야 한다. 라디오헤드의 앨범 제목에서 이름을 따온 레인보우즈(rainbows)는 바로 이 매핑 규칙을 표준으로 정의해, ok를 단순한 스택 기반 명령어 평가기에서 제대로 된 '팬터지 컴퓨터'로 바꾸려는 명세다.
메모리 매핑이라는 핵심 발상
ok는 RAM에서 바이트를 읽어야 할 때마다 ok_mem_read(addr)를, 쓸 때마다 ok_mem_write(addr)를 호출한다. 그런데 이 두 함수는 사용자가 직접 정의하도록 되어 있다. 여기에 트릭이 있다. 특정 주소를 '마법의 위치'로 지정해, 그 주소를 읽으면 표준 입력(stdin)에서 바이트를 가져오도록 함수를 작성할 수 있다. 그러면 ok 어셈블리에서 해당 주소를 읽는 평범한 명령 한 줄이 곧 키보드 입력 읽기가 된다. 레인보우즈가 하는 일은 이런 마법의 주소 값들을 개발자 대신 미리 규정해, 누구나 동일한 방식으로 입출력 장치를 쓸 수 있게 표준 세트를 제공하는 것이다. 이는 외부 주변장치를 특수 메모리 영역에 할당하는 메모리 맵 입출력(MMIO)이라는, 실제 하드웨어에서 오래 쓰여온 기법을 작은 가상 머신에 옮겨온 셈이다.
이미 완성된 장치들
현재 명세에서 완성도가 가장 높은 것은 콘솔 장치 RbConsole이다. stdin에서 읽고 stdout으로 쓰는 것은 물론, C 언어의 argc처럼 명령행 인자 개수를 담는 주소를 둔다. 특정 인자를 읽는 방식이 독특한데, 먼저 arg_index에 몇 번째 인자인지를 쓰고, arg_char_i에 그 인자의 몇 번째 글자인지를 쓴 뒤, arg_char를 읽으면 해당 문자가 나온다. 범위를 벗어나면 0이 읽힌다. 개발자 스스로도 다소 번거롭다고 인정하지만, 대안으로 고려했던 방법들(장치가 임의의 메모리 위치를 조작하게 하거나, 길이가 정해진 버퍼를 두는 방식)은 각각 통제 범위가 너무 넓어지거나 버퍼 초과 처리가 필요해져 택하지 않았다고 밝힌다.
RbArith는 1~4바이트 부호 없는 정수에 대한 곱셈, 나눗셈, 나머지 연산을 더한다. op에 특정 값을 쓰면 x와 y에 대해 해당 연산이 수행되고 결과가 result에 저장되며, width 값에 따라 피연산자의 바이트 폭이 결정된다. 향후 다른 수학 연산이나 난수 생성을 op의 새 값으로 추가할 여지도 열어두었다. 디스크 입출력을 담당하는 RbDisk는 1024바이트 단위의 '블록'을 담는 BlockFile을 기반으로, current 인덱스가 가리키는 블록을 data로 읽어오거나 저장한다.
아직 풀지 못한 숙제, 특히 화면
반면 미완성 장치들에는 설계자의 고민이 그대로 드러난다. RbDatetime은 연·월·일·시·분·초를 각각 메모리에 두는 방식과, 64비트 유닉스 시간을 저장하고 소프트웨어로 날짜를 계산하는 방식 사이에서 갈팡질팡한다. 후자는 ok가 최대 32비트 정수만 지원한다는 제약과 2038년 오버플로 문제에 부딪힌다. 가장 골치 아픈 것은 화면 장치 RbScreen이다. 색 깊이를 2비트 4색부터 RGB332 8비트, RGB565 16비트, 24비트 트루컬러까지 어디로 잡을지, 해상도와 화면비를 고정할지 사용자가 정하게 할지 등이 모두 미정이다. 1024x600 해상도에 24비트 색을 쓰면 프레임버퍼만 약 1800키비바이트, ok가 접근 가능한 전체 메모리의 11%가량을 차지한다는 계산은 작은 가상 머신에서 메모리 예산이 얼마나 빠듯한지를 잘 보여준다.
이 프로젝트의 방향성에는 만드는 사람의 취향이 뚜렷하게 배어 있다. 개발자는 좌클릭 버튼이 망가진 작은 노트북('젠 머신')에서 레인보우즈를 베어메탈로 돌리는 것을 목표 중 하나로 삼고 있어, 모든 소프트웨어가 포인팅 장치 없이 키보드만으로 완전히 쓸 수 있도록 하는 '키보드 우선'을 지향한다. 그래서 마우스 장치는 우선순위가 낮고, 키보드 장치 RbKeyboard는 순환 버퍼로 다중 입력을 추적하고 닌텐도식 컨트롤러 기능까지 넣는 구상이 있다. 오디오와 네트워킹은 토끼굴처럼 깊어질 것을 우려해 미뤘지만, 즐겨 쓰는 제미니(Gemini) 프로토콜의 아주 단순한 클라이언트 장치는 고려 중이라고 한다.
한국의 실무자 입장에서 레인보우즈가 당장 쓸 도구는 아니다. 그러나 이 글은 설계 결정이 어떻게 내려지는지를 투명하게 보여준다는 점에서 읽을 가치가 있다. 인자 접근 방식, 색 깊이, 시간 표현처럼 사소해 보이는 선택 하나하나가 메모리 예산, 정수 폭 한계, 목표 하드웨어, 그리고 설계자의 사용 습관과 맞물려 결정된다. 명세를 쓰는 일만으로도 상당한 작업이라 원래 학부 논문의 컴파일러 구현을 대신해 레인보우즈를 넣으려다 포기했다는 회고는, 추상화 계층 하나를 정의하는 일이 결코 가볍지 않음을 상기시킨다. 현재 목표는 RbConsole, RbDisk, RbArith를 완성한 뒤 간단한 컴파일 언어로 실제 소프트웨어를 만들어 기능을 검증하는 것이며, 명세 주소들은 작업이 진행되며 바뀔 수 있는 유동적인 상태임을 분명히 해둔다.