김 용묵의 절대공간 - 블로그

오늘날이야 x86이라는 컴퓨터 아키텍처가 세계를 완전히 평정해 버려서 PC부터 슈퍼컴까지.. 그야말로 모바일만 빼면 다 쓰이는 것 같다. 그리고 인텔은 그 x86이란 걸 최초로 개발한 본가로 너무나 유명하다.

x86은 아주 오랜 세월 동안 하위 호환성을 최대한 유지하면서 아주 점진적으로 진화해 온 아키텍처이다.
1970년대에 8086과 8088이라는 16비트 CPU에서 시작됐는데, 심지어 더 옛날에 8비트 시절의 8080도 x86의 전신 조상이라고 볼 수 있다. 8008이나 4004까지 가면 너무 멀어지는 것 같지만...;;;

이 x86은 1980년대 중반 80386 버전에서 32비트로 확장됐고, 그로부터 20여 년 뒤엔 64비트로도 확장되어 오늘에 이르고 있다. 다만, x86-64는 인텔이 아니라 AMD에서 처음으로 내놓았다는 것이 특이점이다.
이런 주류 라인인 x86 말고 인텔에서 만든 CPU라니, 뭔가 마이크로소프트의 제품 중에서 Windows, Office, Visual Studio가 아닌 계열을 탐방하는 것 같은 느낌인데.. 이런 것들이 있었다. 다들 32비트였다는 공통점이 있다.

1. iAPX 432 (1981)

인텔에서 개발한 최초의 32비트 CPU는 80386이 아니라 바로 이놈이었다.
16비트 x86이 최대한 저가 보급형에 현실 타협 컨셉으로 개발됐으니, 그 다음 32비트 CPU는 큰 포부를 갖고 실험적인 기능을 몽땅 때려박아 보자~~ 이런 목표를 갖고 개발됐던 것 같다.

x86만 해도 명령어가 아주 촘촘하고 내부 구조가 복잡한 CISC 방식이었는데, 얘는 그 이념이 더욱 극대화됐다. 운영체제나 특정 객체지향 언어 vm에서 소프트웨어적으로 담당할 일을 CPU가 회로 차원에서, 길다란 인스트럭션 하나 직통으로 최대한 지원하는 것을 추구했다.

구체적으로는 그 시절에 특수 분야에서 현역으로 쓰이고 있던 Ada 언어와 아주 찰떡궁합을 이루려 했다. 오오~ 그러면 이 CPU를 타겟으로 하는 Ada 컴파일러는 intrinsic 명령이나 구문이 많이 제공됐겠다.

글쎄, 객체지향 언어라면 RTTI 기능이나 가상 함수/메시지 테이블을 뒤지는 기능이 CPU빨로 직통 지원된다면 그건 바람직한 일이겠지만..
그 시절 기술로 CPU 안에 지나치게 많은 기능을 집어넣는 건 부작용을 야기했다.
CPU 내부가 너무 복잡해졌고 제품의 생산 비용도 치솟았다. 그런 주제에 얘는 동시대의 "16비트" 프로세서인 80286보다도 속도가 훨씬 느려졌다.

그나마 이 CPU의 장점을 살릴 수 있게 코드를 잘 생성하는 컴파일러를 개발하는 것도 영 지지부진했다. 단점은 한 트럭인데 장점도 애매하고.. 총체적인 난국이었으며 결국 이 아키텍처는 실패로 끝났다.

이런 홍역을 치렀으니, 인텔에서 1985년 말에 80386은 기존 8086의 구조를 최대한 유지하고 호환성도 살리면서, 정말 바꿔야 하는 부분만 16비트에서 32비트로 확장하는 컨셉으로 만들어졌다.
32에서 64비트로 넘어갈 때 Itanium은 망하고(너무 파격적) AMD64가 살아남았었다(좀 보수적). 그런데 이와 같은 유형의 삽질이.. 옛날에 32비트로 넘어갈 때도 인텔 내부에서 이미 벌어졌다고 볼 수 있다.

2. i960 (1988)

iAPX 432의 실패 이후에 인텔에서 오랜만에 새로 만든 비x86 CPU는 바로 얘였다. 정확히는.. 처음엔 지멘스와 공동 개발을 시작했지만 지멘스 쪽이 프로젝트를 포기하고 중도 이탈하면서 최종 결과물이 인텔 것이 되었다.

i960은 CISC가 아닌 RISC 방식으로 설계됐으며, 애초에 범용 컴퓨터가 아니라 산업용 임베디드 MCU 용도로 만들어졌다. 에, 그러니까 절대적인 성능이 뛰어나지 않더라도 특정 분야 연산만 겁나 잘한다거나, 열악한 환경에서도 퍼지지 않고 끈질기게 잘 돌아가는 것 말이다.
얘는 처음에 군용으로 납품되었으며 초창기 F-22 전투기의 내부에도 들어갔다고 한다. 미군 전투기..?? 거기야말로 오랫동안 Ada 언어를 사용했던 곳이 아닌가? 반면교사 선배격인 iAPX 432가 관심을 가졌던 그 언어 말이다.

i960은 인텔이 만들었던 비x86 CPU 중에서는 가장 성공했다. 범용 컴퓨터가 아닌 덕분에 특정 분야에서 고정된 고인물 수요가 보장되어서 수십 년 동안 생산되고 쓰였다.
얘는 일본 SEGA에서 개발한 버추어 파이터 2의 플랫폼인 MODEL2 기판에 채택되어 쓰이기도 했다.

"게임 크리에이터 열전"이라는 20년 전의 일본 만화에서 '스즈키 유 - 버추어 파이터' 편을 보면, 그 시절 기계로 현란한 3D 그래픽 애니메이션을 구현하기 위해 전투기에 들어가는 CPU까지 구해서 기판을 만들었다는 얘기가 있었는데..
1편 때는 조종사 훈련용 전투기 시뮬레이터에 들어가는 CPU와 GPU를 도입했었다. (MODEL1, NEC V60) 그러다가 MODEL2는 전투기 실물에 들어가는 인텔 i960 CPU가 쓰인 것이다. 그런 차이가 있다~!

3. i860 (1989)

얘는 960과 동시기에 같은 회사의 다른 팀에서 나란히 개발되고 있던 또 다른 32비트 CPU였다. 960보다 숫자가 작지만 960보다 나중에 출시됐다.
얘는 산술· 과학 계산을 빡세게 하는 워크스테이션이나 슈퍼컴을 겨냥하여 FPU를 64비트 스케일로 내장했다. 그리고 명령의 병렬 수행을 여러 모로 의식해서 명령 체계를 RISC를 넘어 VLIW 형태로 설계했다. 사실상 32비트판 Itanium이고 Itanium의 정신적 선배나 마찬가지였다.

하지만 i860은 컴파일러가 특정 분야의 프로그램 한정으로 이 CPU의 특성을 잘 살리는 방향으로 코드를 잘 번역하고 잘 생성해 줘야만 제 성능을 낼 수 있었으며.. 그러기가 쉽지 않았다. 다른 대부분의 상황에서 얘의 성능은 기존 CPU나 동급 경쟁사의 CPU보다 뛰어나지 못했다. 그래서 얘는 얼마 못 가고 실패했다.

인텔은 그래도 이 설계 이념을 버리지 못했다. x86이 당장 현실적으로 상업적으로는 잘나가고 있지만 얘는 레거시 때문에 구조적으로 너무 지저분하긴 했기 때문이다.
그러니 나중에 64비트로 갈아탈 때는 iAPX 432와 i860의 이념을 계승하면서 단점을 보완은 했다고 생각하면서 Itanium을 개발했다. 하지만 Itanium은 실패한 선배의 전철을 거의 그대로 밟으면서 역시 처절하게 실패했다.

그래도 인텔 i960과 i860의 개발진은 훗날 x86 동네에서 Pentium Pro CPU를 개발했다. 멀티미디어 지원에 필요한 병렬화 고속 연산 명령인 MMX를 만들어서 그 이념을 x86에다가 실현해 냈다.

사실은 마소의 Windows NT라는 것도 맨 처음, 최초로 타겟으로 설정한 아키텍처는 놀랍게도 이 i860이었다고 한다. 마소가 전통적으로 인텔 진영과 사이가 좋기도 했으니.. 하지만 본가이던 i860이 망조가 들고, NT는 처음부터 이식성도 있게 설계되었기 때문에 곧 x86, MIPS 등의 아키텍처로 포팅된 것이다.

나중에 Windows 2000은 NT 버전 5.0 급이었는데, 얘도 64비트용은 Itanium이 정식 출시되기를 기다리면서 대부분의 기간을 DEC Alpha 환경 내지 Itanium 껍데기 시뮬레이터에서 개발됐다고 한다.
하지만 이번에도 인텔 CPU가 통수를 치는 바람에 Win 2000은 사실상 x86 전용으로, WinNT의 역사상 지원 CPU가 가장 적은 버전으로 개발돼 버렸다.

글쎄, 인텔이 구닥다리 X86을 버리려고 1990년대부터 삽질했었다면, 마소는 NT 커널을 버리려고 2000년대 중후반부터 이것저것 실험하고 노력했던 것 같다. 하지만 현실에서는 이 시도 역시 전혀 성공하지 못했다.

• 과거에 Windows 3.0은 real, standard, enhanced 이렇게 x86 하에서 실행 모드가 다양했다.
• 그 반면, Windows NT 3~4는 x86, MIPS, PowerPC 등 지원하는 CPU가 다양했다.
• Windows 2000은 x86 전용이 돼 버렸지만 그 32비트 한계 하에서 PAE나 /3GB 같은 옵션을 제공하면서 메모리를 최대한 많이 뽑아내려고 노력한 흔적이 들어갔다.
• Windows의 역사상 Itanium을 제대로 지원했던 버전은 XP가 유일했다.

Posted by 사무엘

컴퓨터 업계에서 인텔의 경쟁사라고 하면 가장 먼저 (1) 동급의 x64 CPU를 만들어서 경쟁하는 AMD,
(2) 아키텍처 차원에서 x64에 도전하는 ARM 내지 애플, 혹은 심지어 (3) 울나라 삼성 전자까지 떠올릴 수 있다. 인텔이 메모리 반도체에도 손을 뻗치고 있기 때문이다.
그런데 인텔은 저것들보다는 대외 인지도가 낮은 분야에서 AT&T와도 경합한 게 좀 있었다.

1. 바이너리: 오브젝트 파일 포맷

C/C++ 언어로 코딩을 한 뒤에 컴파일을 돌리면 생기는 자잘한 obj 파일들 말이다. 기계어 코드를 담는 이 컨테이너 껍데기의 포맷은 누가 언제 제정했을까?
x86 진영에서는 CPU 본가인 인텔에서 제정한 OMF 방식이 16비트 시절부터 널리 쓰였다. 볼랜드니 마소니 컴파일러가 다르더라도 obj 파일은 호환됐기 때문에 툴을 달리하여 링크가 가능했다.

그러나 마소에서는 32비트 Windows NT를 개발하면서 실행 파일 포맷을 바꾸고(NE에서 PE), 빌드 툴체인도 싹 갈아치웠다. 단순히 OMF의 32비트 확장을 쓰는 게 아니라 obj/lib의 포맷도 AT&T에서 제정한 COFF 방식으로 바꿨다. 그 반면, 볼랜드 컴파일러들은 32비트에서도 여전히 OMF 방식을 쓰면서 서로 파편화가 발생하게 됐다.

그 시절에 마소에서는 빌드를 더 편하게 하기 위해서, 로딩을 더 빠르게 하기 위해서(메모리 매핑), 거기에다 이식성까지 고려해서 같은 여러 명분으로 COFF를 도입했었다. 다만, 지금은 그런 명분이 기술적으로 많이 옅어지고 사라지기도 했다.

그러고 보니 GNU 툴킷의 도스용 버전에 속하는 djgpp 컴파일러도 라이브러리· 오브젝트 파일 포맷은 COFF 방식이었던 걸로 기억한다. 바이너리 에디터로 들여다보면 arch! 앞에 이런 문자열이 있고.. "이건 마소 진영과 오픈소스 진영이 공통이네?" 이런 생각을 예전에 했었다.

2. 텍스트: 어셈블리어 문법

자기네 x86 기계어를 간단한 숫자와 영단어 나열만으로 풀어서 표기하는 어셈블리어 말이다. 이것도 인텔 식 문법과 AT&T 식 문법이 공존한다. 이건 단순히 '어셈블러' 제조사 간의 문법 차이가 아니라 '어셈블리어' 차원에서의 더 저수준 차이점이다.

간단하게는 숫자 앞에 $, 레지스터 이름 앞에 %가 막 붙어 있는 게 AT&T 문법인데, 본인 역시 Visual C++이 표시해 주는 인텔 문법에만 익숙하다. 하지만 역시 리눅스 진영 gdb 같은 데에서는 AT&T 문법이 주류이다.
현업에서 어셈블리어를 직접 짤 일은 없지만, 그래도 프로그램을 디버깅 하다 보면 디버거가 디스어셈블리해 준 어셈블리어 코드를 보게는 된다.

마소는 이거 문법은 딱히 AT&T 식으로 갈아타지 않았고 인텔 문법을 고수하는 듯하다. Macro Assembler 같은 기존 제품과의 호환 문제가 있기 때문인 듯하다.
뭐, 어차피 같은 CPU 아키텍처이고, 짜는 게 아니라 읽기만 한다면야 자잘한 표기 차이는 그렇게 심각한 차이점은 아닐 것이다.

프로그래밍 언어라는 건 적당히 고급 언어를 표방하면서 실용성을 갖춘 게 인기를 얻고 대중화되는 편이다.
그럼 실용성 대신에 한쪽으로 특화된 언어는 (1) 함수형처럼 수학 내지 순수주의 쪽으로 특화되거나, 아니면 (2) 어셈블리어처럼 기계 지향적인 쪽으로 특화되는 것 같다.

한 소프트웨어의 모든 코드를 저런 특화 언어만으로 작성하는 건 아무래도 무리이다.
그래서 기존의 실용적인(?) 다중 패러다임 언어들은 저 (1), (2)의 특성을 제한적으로 부분적으로 제공하곤 한다. 그게 (1) 람다 아니면 (2) 인라인 어셈블리인 셈이다.;;

요즘 세상에 대학교 컴공과에서 어셈블리어 코딩 실습을 하는 건 군대에서 총검술, 사관학교에서 승마 실습을 잠깐 하는 것과 아주 비슷한 모양새인 것 같다.
비록 현대의 전장이나 현대의 소프트웨어 개발 방법론과는 완전히 동떨어져 버렸지만, 코딩이라는 전투에서 백병전이 어셈블리어 실습이 아니겠나..;; =_=;; 실무에서는 쓸 일이 없지만 컴공 엔지니어를 양성한다는 학교에서는 컴퓨터의 밑바닥 모습을 이런 식으로라도 경험시켜 줄 필요가 있을 것이다.

Posted by 사무엘