6502 명령어 세트, 첫 어셈블리 언어로 적합한 이유

• 어셈블리는 CPU 구조와 직접 맞닿아 있어 첫 학습 대상이 중요한데, 6502는 단순한 구조와 실제 생태계를 함께 갖춘 입문용 플랫폼임
• 레지스터 6개와 원래 명령어 56개만으로 레지스터, 로드/스토어, 논리·산술 연산, 분기 같은 기본 개념을 빠르게 익힐 수 있음
• Apple II, Commodore VIC 20, Commodore 64, BBC micro 등에 쓰인 실제 CPU라 에뮬레이터와 재현 기기, 무료 자료를 활용한 실습 기반 학습이 쉬움
• Easy 6502는 웹에서 바로 코드를 써볼 수 있는 JavaScript 기반 어셈블러와 시뮬레이터를 제공해 짧은 시간에 감을 잡기 좋음
• Z80, 현대 RISC, x86-x64도 배울 가치가 있지만, 첫 단계에서는 복잡도가 낮은 6502가 학습 부담을 줄여줌

---

6502가 입문용으로 적합한 이유

• 어셈블리 프로그래밍은 고수준 언어보다 하드웨어와의 연결이 강해, 처음 접하는 CPU가 학습 난이도를 크게 좌우함
• 6502 어셈블리는 오늘날 실무 애플리케이션 작성에 쾌적한 환경은 아님
  • 레트로 프로그래밍 자체에 관심이 없다면 6502에 오래 머물 필요는 없음
• 입문용 플랫폼으로서의 장점은 단순함과 실재성임
  • 단순한 구조 덕분에 기본 개념을 빠르게 익힐 수 있음
  • 실제 기기, 에뮬레이터, 책과 온라인 자료가 많아 학습 경로를 잡기 쉬움

• 레지스터와 명령어가 작게 유지됨

  • 6502는 레지스터가 6개뿐임
    • 누산기 1개
    • 인덱스 레지스터 2개
    • 상태 레지스터
    • 스택 레지스터
    • 프로그램 카운터
  • 6502에서 유일한 16비트 레지스터는 프로그램 카운터임
  • 적은 레지스터 수는 실제 애플리케이션 작성에는 제약이지만, 레지스터의 역할과 동작을 이해하는 데 도움이 됨
  • 원래 6502 명령어 세트는 56개 명령어만 포함함
  • 이 작은 명령어 집합으로도 주요 명령어 유형을 배울 수 있음
    • 로드/스토어
    • 논리 연산
    • 산술 연산
    • 분기
  • 이런 유형들은 현대 CPU에도 어떤 형태로든 남아 있음
  • x86-x64는 레지스터와 명령어 수를 세는 것부터 쉽지 않고, ARM 같은 현대 RISC 명령어 세트도 작고 단순하다고 보기 어려움

실제 생태계와 다른 선택지

• 오래됐지만 살아 있는 생태계

  • 6502는 1970년대 중반 MOS Technology가 Motorola 6800의 저렴하고 단순화된 버전으로 도입함
    • 같은 팀이 이전에 Motorola 6800을 개발했음
  • 이후 빠르게 인기를 얻어 여러 유명 마이크로컴퓨터에 사용됨
    • Apple II
    • Commodore VIC 20
    • Commodore 64
    • BBC micro
  • 이런 기기들의 에뮬레이터를 찾기 쉽고, 일부는 현대적 재현 기기도 있음
  • 6502의 후속 제품은 글 작성 시점에도 생산 중이며, Olimex의 Neo6502 같은 새 기기도 6502 계열을 실행함
  • 무료 학습 자료는 인터넷에 많고, 상당수를 6502.org에서 찾을 수 있음

• 바로 실습할 수 있는 학습 자료

  • Easy 6502는 Nick Morgan의 전자책으로, 짧게 6502를 접해보려는 학습자에게 적합함
  • 텍스트와 이미지뿐 아니라 JavaScript로 작성된 6502 어셈블러와 시뮬레이터를 포함함
    • 웹페이지에서 간단한 6502 어셈블리 코드를 바로 작성할 수 있음
  • Visual6502.org는 어셈블리 학습 도구라기보다 6502의 단순함을 시각적으로 보여주는 자료에 가까움

• 다른 입문 후보와의 차이

  • 교육용으로 만든 가상 CPU는 깨끗하고 “완벽한” 명령어 세트를 가질 수 있지만, 6502만큼 풍부한 학습 자료와 커뮤니티를 갖추기 어려움
  • Z80, 6809, 68000 같은 레트로 CPU도 좋은 선택지임
    • 세 CPU는 진지한 프로그래밍에는 6502보다 더 낫다고 평가됨
    • 기본 개념 학습에서는 6502의 단순함이 더 유리함
  • Z80은 6502보다 레지스터가 훨씬 많고 대체 레지스터 세트도 있어 시작하기가 덜 쉬움
  • ARM, MIPS, RISC-V 같은 현대 RISC 아키텍처는 어느 시점에는 진지한 어셈블리 프로그래머가 배워야 할 대상임
    • 다만 입문용으로는 이상적이지 않음
    • 이들의 단순함은 명령어 세트보다 칩 내부 구현 측면에 더 가까움
  • 현대 마이크로프로세서는 대부분 고수준 언어로 프로그래밍되며, 직접 어셈블리 명령어를 쓰는 경험이 CPU 설계 우선순위에서 높지 않음
  • ARM64에서 64비트 상수를 레지스터에 로드하려면 비트 시프트를 포함해 4개 명령어가 필요할 수 있음
    • 6502에서 상수를 레지스터에 로드하는 과정은 그에 비해 단순함
  • x86-x64는 현대 데스크톱과 서버에서 가장 대중적인 명령어 세트라고 볼 수 있고 ARM이 따라잡는 중임
    • 32비트 크기 제약을 받지 않고, 피연산자 수가 가변적인 풍부한 명령어가 있어 ARM보다 코딩이 쉬운 측면도 있음
    • 하지만 초보자에게는 여전히 매우 복잡하며, 40년의 역사가 x86-x64를 더 단순하게 만들지는 않음

[GN⁺]

Hacker News 의견들

• 6502의 단순함이 68000보다 낫다는 데는 동의하기 어려움
  68000은 레지스터가 더 많고 자료형 폭도 넓지만, 구조는 균일함. 사실상 A와 D 두 종류가 D0~D7, A0~A7로 반복되는 형태라 D0에서 되는 일은 D3에서도 가능함. 구조의 단순함은 프로그래밍의 단순함과 균형을 맞춰야 하고, 6502는 조금만 복잡한 프로그램을 짜도 제약에 계속 부딪힘
  작은 기계의 한계를 우회하는 법을 배우는 가장 좋은 길은 오히려 그 한계를 무시하고 숙련된 소프트웨어 엔지니어가 되는 것임. 초보라면 주소 지정 방식이 더 많고, 큰 배열을 다루기 쉽고, 레지스터와 정수 폭이 넉넉한 쪽에서 시작하는 편이 낫다

  • 비슷하지만 다른 관점에서 봄. 지난 수십 년 동안 6502, 68k, z80, x86/64를 주로 데모 쪽에서 다뤘는데, 이 글이 AI가 쓴 건 아닌가 싶기도 했음
    6502에 레지스터가 6개라 단순하다고 주장하지만, 6502를 일주일만 만져봐도 사실상 세 개의 레지스터를 다룬다는 걸 알게 됨. 그래서 세마포어 CPU라는 별명도 나옴
    6502는 재미있고 깔끔하지만, 현대적인 접근을 원하면 적합하지 않음. 90년대식 영광의 길을 따르고 싶다면 MIPS부터 시작하거나, 그냥 Neon으로 시작하는 편이 나음. Z80도 레지스터와 복잡성을 생각하면 오늘날 만나는 것들과 더 비슷하다고 볼 여지가 있음
    현대 어셈블리 자체가 본질적으로 복잡한 건 아님. FASM부터 시작하면 어렵진 않지만, 저수준 접근은 언제나 금방 복잡해짐. 그러다 매크로를 만들기 시작하고, 결국 자기만의 가난한 C 비슷한 것을 얹게 됨
  • 작은 기계의 한계를 우회하는 법을 배우는 건 숙련된 소프트웨어/하드웨어 엔지니어가 되는 좋은 단계임
    작은 시스템의 장점은 실리콘부터 운영체제, 소프트웨어까지 전체를 완전히 이해할 수 있다는 데 있음
    6809는 68K보다 단순하고 6502보다 강력하며 직교성이 좋지만, 같은 수준의 소프트웨어 기반은 없음. Motorola는 6809와 68K의 명령어 집합과 프로그래머 관점 아키텍처에서 꽤 좋은 방향을 잡았다고 봄. PDP-11/VAX와 NS32K도 비슷하게 직교적인 편으로 기억함
  • 6502는 Z80보다 장난감용 어셈블리로 낫지만, 그게 대단한 말은 아님. AVR 8비트 명령어 집합보다 명확히 낫다고 보기도 어려움
    더 현대적인 플랫폼을 생각하면 MC68k보다 RISC-V를 가르치는 쪽이 강한 설득력이 있음. RISC-V는 기본 정수 명령어 집합만 보면 매우 단순하고 우아하면서도 ARM, Aarch-64, MIPS 같은 현대 아키텍처와 닮아 있음. 32비트와 64비트가 모두 있고 공식 문서도 접근성이 좋음
    MC68k에는 오늘날 별로 관련 없는 특이점이 너무 많음. 장점이라면 여러 하드웨어 플랫폼에서 쓰였고 아직 활발한 레트로 커뮤니티가 있다는 정도인데, 그건 흥미 요소에 가깝지 실제 관련성은 낮음
  • 68K도 24비트 버스, 정렬 제약, 배열 인덱싱 지원의 애매함 때문에 약간 불편함. 배율 인자가 없다는 점도 걸림
    68020은 명령어 집합 아키텍처가 C에 가까워질 수 있는 거의 최대치에 가깝고, 사용감이 매우 좋음
  • 6510으로 프로그래밍을 배웠지만, 68000 명령어 집합이 훨씬 더 좋고 읽고 배우기 쉬웠다는 데 동의함. 나라도 68000을 고르겠음
    다만 초기 Commodore 컴퓨터에서 65XX를 쓰는 건 매우 보람 있었음. 메모리 보호가 없어서 비디오 메모리를 직접 바꾸고, 스프라이트·폰트·테두리·인터럽트를 건드리고, 자기 수정 코드도 작성할 수 있었음. Amiga의 68000 어셈블리는 더 안전하고 통제된 환경이었음

• 어셈블리를 배우려는 첫 명령어 집합으로 6502는 좋지 않다고 봄. 영리하지만 깊이 결함 있는 아키텍처의 특이점을 상대하는 데 시간을 많이 쓰게 됨
  그 우회 관용구들은 당시 MOS가 가진 도구와 예산 제약에 묶이지 않은 더 나은 아키텍처로 잘 이어지지 않음
  작지만 강력하고 약간의 특이점이 있는 명령어 집합을 배우고 싶다면 ARM v6M이 낫다. 지금도 의미 있게 생산되고 있고, 최신 오픈소스 도구 체인에서 디버거·컴파일러·어셈블러·링커 지원도 좋음
  아키텍처의 개방성을 중요하게 보고 아직 덜 성숙한 플랫폼을 감수할 수 있다면 RISC-V MCU를 고르면 됨. 결정 못 하겠으면 RP2350을 고르면 됨
  ARMv6M 명령어 집합은 작고, 상수 적재도 문서대로 PC 상대 적재를 쓰면 길고 지루한 명령어열이 필요하지 않음. 자기 수정 코드나 제로 페이지로 메모리를 인덱싱할 필요도 없고, 레지스터 폭이 주소 공간과 같음. 32비트라서 오히려 대부분의 8/16비트 명령어 집합보다 배우고 가르치기 쉽다. 심심하게 들린다면 걱정할 필요 없음. ARMv6에도 코드 골프에 쓸 특이점은 충분함

  • 6502 아키텍처를 좋아하지만, 예전 컴퓨터에 관심 있는 입문자가 이전 어셈블리 경험이 없다면 보통 다른 쪽으로 안내함
    PIC16 어셈블리로 시작했고 여러 아키텍처를 조금씩 다뤘지만, 깔끔함으로는 MIPS32가 가장 마음에 들었음
    사소한 보충을 하자면, Western Design Center에서 새로 만든 6502, 6502 코어 MCU, 주변 칩을 아직 살 수 있음. Mouser 같은 곳에서도 판매함
    https://www.mouser.com/c/?m=Western%20Design%20Center%20%28W...
  • 예전에 6502 어셈블리를 많이 썼는데, 8비트 아키텍처를 상대하는 데 시간을 꽤 많이 씀
    16비트 숫자 두 개를 곱하는 것만 해도 코드 덩어리가 필요함. 새 프로그래머가 이런 것과 씨름하는 건 유용해 보이지 않음
    말한 대로 초기 ARM 명령어 집합은 좋은 선택임
  • ARM도 입문자에게는 즉값이 명령어 안에 들어가는 방식 때문에 몇 가지 아픈 지점이 있음. 어떤 즉값이나 오프셋은 되고 다른 것은 왜 안 되는지 직관적이지 않을 수 있음
    물론 여러 어셈블리 언어 전반에 걸친 문제지만, 처음에는 이런 문제가 없는 명령어 집합으로 시작하면 좋겠음
  • “깊이 결함 있다”는 게 무엇을 가리키는지 짐작도 잘 안 됨
  • Ben Eater의 65C02 브레드보드 시리즈[1]를 계속 떠올리게 됨. 그 영상에서 하는 일을 ARM CPU로도 재현할 방법이 있을까?
    [1] https://youtube.com/playlist?list=PLowKtXNTBypFbtuVMUVXNR0z1...

• 학부생에게 어셈블리를 여러 해 가르쳐 온 입장에서 말하자면, 6502가 초보자에게 좋다는 데는 동의함. 다만 그 이유가 6502 언어 자체의 장점만은 아님
  68K, MIPS, ARM, x86 등을 가르쳐 봤고, 6502를 가르쳤을 때 학생 반응이 좋았던 가장 큰 이유는 CPU 주변의 맥락 때문이었음. 우리는 6502로 이해하기 쉬운 실제 기계, 즉 Nintendo Entertainment System을 프로그래밍했음
  기초적인 메모리 매핑 입출력, 운영체제 없음, 파이프라인 명령 없음, 지연 슬롯 없음, 네트워크 없음, 불필요한 잡음 없음. 내부에 클록, CPU, 몇 개의 메모리 주소, 보조 칩, 메모리 주소에 매핑된 입출력이 있는 단순한 상자에 가까움. 6502가 가장 단순한 명령어 집합은 아니지만, 이 시스템의 단순함이 큰 도움이 됨
  6502의 제약도 학생들이 명령어가 왜 그렇게 생겼는지 이해하는 데 중요했음. CPU는 당시 제약 안에서 설계되고 배선됐고, 그 점이 프로그래밍 방식에 반영됨
  초보자 교육에 6502와 NES를 고른 것은 성공적이었음. 6502라서라기보다, 6502가 비트를 옮기는 시스템 자체를 단순하게 만들도록 강제했기 때문임
  학생들이 6502를 만지고 NES 타일이 화면에서 움직이는 걸 본 뒤에는, 68000이 어떻게 다르게 처리하는지, MIPS가 어떻게 등장했는지, 파이프라이닝과 지연 슬롯을 어떻게 활용하는지, RISC와 CISC 차이를 어떻게 비교하는지로 자연스럽게 확장하기 쉬웠음. 기초가 있으면 발전은 아주 단순해짐

• 현재 쓰이는 명령어 집합을 배울 게 아니라면, PDP-11 어셈블러가 좋은 출발점으로 거의 언급되지 않는 게 조금 놀라움
  아마 내가 제대로 처음 배운 게 PDP-11이라서 그럴 수도 있지만, 초기 마이크로프로세서들은 모두 한 걸음 후퇴처럼 느껴졌음. Z80 어셈블리를 몇 년 쓰긴 했지만, 지금은 추천하지 않음. 직교적인 명령어 집합이 아니고, 6502는 레지스터가 너무 부족해서 어셈블리 작성 감각을 제대로 주기 어렵다

  • 요즘 PDP-11을 구하기는 꽤 어렵고, 운영체제나 컴파일러 등을 확보하는 것도 쉽지 않음
    PDP-11을 좋아한다면 MSP430에서는 비슷한 장점을 약간 제한된 형태로, 68000에서는 약간 강화된 형태로 얻을 수 있음
    하지만 사실 그런 유물은 잊고 RISC-V를 배우는 게 최선임. 아니면 여러 Arm 변형 중 하나를 고르면 됨. 개인적으로는 2000년대 중반에 많이 다뤘던 ARM7TDMI에 감정적으로 끌림. Thumb 모드는 원래 Arm 모드보다 조금 더 배우기 쉬울 수 있지만, 둘 다 RISC-V만큼 만족스럽진 않음
  • 동의함. PDP-11은 훨씬 쾌적해서 비교가 안 됨
    주소 지정 방식이 RISC보다 개념적으로 복잡하다고 주장할 수는 있지만, 실제로는 6502 주소 지정 방식이 PDP-11보다 이해하기 더 어려울 가능성이 큼
  • PDP-11 어셈블리를 배우면 C의 일부 관용구가 왜 그런지도 이해됨. 예를 들어 포인터의 포인터는 아키텍처에 바로 대응되는 네이티브 주소 지정 방식임
  • -11 명령어 집합은 공학적 걸작임. DEC는 마이크로컴퓨터 사업을 완전히 지배하는 데 필요한 것을 모두 갖고 있었음
    하지만 DEC는 그 기회를 외면했고, IBM이 둔탁한 8086 명령어 집합으로 그 자리를 가져감
    이제 -11을 배울 목적은 더 이상 없음

• 어떻게 그런 결론이 나오는지 잘 모르겠음. 학생들이 처음 컴퓨터 프로그래밍을 접할 때는 현실 용도가 없는 장난감/소형 언어로 시작하는 게 말이 될 수 있음. 하지만 어셈블리는 처음 배우는 언어가 아니어야 함
  어셈블리는 매우 실용적인 도구이고, 보통 디버깅과 역공학에 많이 쓰임. 그런데 왜 오래전에 사라진 플랫폼의 어셈블리에 시간을 써야 하는가
  어셈블리를 배우는 가장 좋은 방법은 실험임. 좋아하는 언어로 코드를 쓰고 중간 어셈블리 출력을 보거나, objdump나 gdb로 내부를 들여다보면 됨. 바꿔 보고 어떤 일이 일어나는지도 확인할 수 있음
  예전 컴퓨터 에뮬레이터로도 가능하지만 더 어려움. 화면에 텍스트 하나 찍는 일에도 그 컴퓨터의 아키텍처, 하드웨어, ROM 기능까지 배워야 하고, 이 지식은 x86-64의 Linux나 Windows에는 거의 적용되지 않음

  • C를 이해하는 데 고생하다가 68HC11에서 16진수와 어셈블리 프로그래밍을 배우고 나서야 길이 열렸음
    완전 초보에게 포인터 같은 개념은 너무 추상적이고 난해했는데, 어셈블리에서 간접 주소 지정을 배우자 C에 왜 포인터가 있고 어떻게 작동하는지가 갑자기 명확해짐
    이전에는 Python을 주로 썼고 훨씬 더 추상화되어 있었음. 포인터 같은 기능이 하드웨어와 성능 제약 때문에 존재한다는 걸 사람들이 잊곤 함. CPU 내부에서 실제로 무엇을 왜 하는지 모르면 직관적인 이해가 제한됨
  • 몇 달 동안 하드웨어를 만지고 어셈블리를 프로그래밍해 보면, 고수준 언어와는 전혀 다른 방식으로 컴퓨터의 기본 동작을 이해하게 됨
    고등학교 이후로는 어셈블리를 한 줄도 짜지 않았지만, 연산이 어떻게 실행되고 레지스터가 어떻게 작동하는지에 대한 기초 이해 덕분에 프로그래밍과 최적화의 이유, 조건, 예외를 훨씬 쉽게 이해하게 됨. 깔끔하고 효율적인 코드도 더 높이 평가하게 됨
  • 우리는 열 살 아이 때도 BASIC 프로그래밍 만화책 다음의 두 번째 언어로 꽤 잘 해냈음
    과거를 조금 맛보고 싶다면 여기 있음
    https://www.atariarchives.org/
  • 프로그래밍을 배우는 길은 대략 두 가지임. 추상 개념에서 실제 구현으로 내려가는 하향식 방식, 예를 들면 SICP, 그리고 구체적인 저수준 코드에서 시작해 추상화가 자연스럽게 생겨나게 하는 상향식 방식임
    전자공학을 공부했기 때문에 자연스럽게 어셈블리(Motorola HC11)부터 시작했음. 과정이 끝날 때쯤 모두가 독립적으로 for 루프 같은 것을 위한 매크로를 만들었고, 거기서 C로 자연스럽게 넘어갔음. C 과정이 끝날 때는 C 스타일 객체 지향도 자연스럽게 나타났고, 다음 C++ 과정으로 이어졌음
    이 접근의 단점은 함수형 패러다임이나 일반적인 비명령형 패러다임으로 이어지는 점진적 경로가 없다는 것임. 또 언어가 내부에서 어떻게 작동하는지 계속 생각하는 습관이 생기는데, 이게 역효과가 날 때도 있음. Haskell을 배우려 할 때도 인터프리터가 어떻게 동작하는지부터 이해하려고 머리가 움직였음
    어셈블리를 배우는 건 언어만이 아니라 버스, 메모리 매핑 주변장치 등 기계가 어떻게 작동하는지 이해하는 일임. 오래된 플랫폼에서는 이 부분이 훨씬 단순함. 그래서 ARM 명령어가 HC11의 CISC 명령어보다 배우기 쉽더라도, 나머지 모든 것은 초보자에게 HC11 쪽이 더 친절함
  • dmd 컴파일러에서는 -vasm으로 컴파일하면 생성된 어셈블리를 컴파일 중에 보여줌. objdump나 -S를 쓰면 되지 않느냐며 별로라는 평가도 받았지만, 직접 써 보면 왜 편한지 알게 됨. 객체 파일을 만들기 위한 방대한 상용구 없이 어셈블리만 바로 출력하기 때문임
    예를 들어 AArch64 코드 생성기, 더 구체적으로는 부동소수점 코드 생성을 작업 중이고 이런 함수가 있음
    float test(float a, float b) { return a * b; }
dmd -c test.c -arm -vasm으로 컴파일하면 주소, 16진수 명령어, 명령어 니모닉, 명령어 명세 URL이 출력됨
    코드가 완전히 맞지 않다는 건 알고 있음. 아직 작업 중이라고 했음 :-)

• 내게는 6502 명령어 집합이 좋은 첫 어셈블리 언어였음
  1977년에 Oregon의 작은 오두막에 살고 있었고, 심심풀이로 Apple II를 샀음. 1년 안에 나중에 Apple Writer가 된 프로그램을 작업하게 됐고, 전부 어셈블리로 작성했음
  https://en.wikipedia.org/wiki/Apple_Writer
  여기서는 6502 어셈블리가 꽤 투박하고 쓰기 어렵다고 하는데, 돌이켜 보면 동의함. 다만 1977년에는 비교할 기준이 없었음
  Apple II에는 빠른 고수준 언어가 없었기 때문에, 내 작은 프로그램은 대안 부족 덕분에 Apple 제품이 됨
  생각해 보면 Apple Writer는 8KB RAM 안에 들어갔지만 실제로 일을 했음. 사람들이 주소 목록을 처리하는 데 쓰던 매크로 언어도 있었음
  최근 DeepSeek을 로컬에서 더 쉽게 돌리려고 메인 시스템을 96GB RAM으로 올렸고, RTX 4090도 있음. 문득 이 RAM이면 Apple Writer를 거의 1,200만 개 담을 수 있다는 걸 깨달았음
  꽤 초현실적이지만, 1977년 이후로 이런 말을 할 일이 여러 번 있었음

• 시작용 어셈블리 언어로는 RISC-V를 선호함. 설계가 좋고 더 직관적이며, GCC, LLVM, Rust 같은 현대 언어와 도구 지원이 있고, QEMU와 실제 구매 가능한 하드웨어에서 돌아가기 때문임

  • ARMv7도 이 기준을 충족하고 쓰기 좋음. Acorn Archimedes의 BBC Basic 안에서 인라인으로 사용할 수 있음
  • 마지막으로 확인했을 때는 RISC-V에 이름값을 할 만한 매크로 어셈블러가 아직 없었음
  • “실제 구매 가능한 하드웨어”라면, 마지막으로 확인했을 때 65C02도 아직 제조·판매 중이었음
    무려 14MHz로도 동작할 수 있음

• 6502 명령어 집합의 단순함이라는 주제는 개인적으로 거슬리는 지점임. 그런 단순함이 좋다고 생각하는 사람은 Hello World 이후로 나아가 본 적이 없어 보임
  6502로 중간 정도 복잡한 것을 프로그래밍하는 건 어렵다. 8비트는 너무 제한적이고, 예를 들어 Commodore 64의 화면 주소 지정만 봐도 그렇다. 곱셈과 나눗셈은 직접 구현해야 하고, 16비트 덧셈/뺄셈도 단순하긴 하지만 효율적으로 하려면 결코 사소하지 않음
  기본 어셈블리를 배우려는 목적이라면 8086+DOS 플랫폼이 비교하면 훨씬 다루기 쉬움

  • 첫 어셈블리 접촉이라는 맥락에서는 곱셈/나눗셈을 직접 구현해야 하는 게 오히려 좋음
    여러 곱셈·나눗셈 알고리즘을 어셈블리로 옮기는 건 배우기에 아주 좋은 방법임
  • 제약이 재미의 일부임. 8086 어셈블리는 그만큼 재미있지 않음
    어차피 x86-64, RISC-V, ARM이 아닌 지금과 관련 없는 것을 배우려는 거라면, 8086의 장점이 뭔지 잘 모르겠음
  • 내가 가장 많이 쓴 어셈블리는 아마 8086, 정확히는 실제 모드의 80286일 것임
    매 순간이 좋았고, 세그먼트 레지스터도 별로 거슬리지 않았음

• 컴퓨터과학 중심 기술학교에 다니는데, 레트로를 좋아하고 자기 아케이드 기계를 보여주기 좋아하는 정보학 교수가 정해진 수업 계획인 8808 어셈블리 대신 6502에 집중했음
  솔직히 인생에서 가장 좋은 학습 경험 중 하나였고, 다른 방식이었으면 좋겠다고 생각하지 않음. Ben Eater의 브레드보드 컴퓨터까지 만들게 해서 특히 손으로 직접 만지는 느낌이 강했고 정말 흥미로웠음

• 어셈블리 언어를 처음 접한 건 PDP-10이었고, 가진 것은 DEC-10 프로세서 매뉴얼뿐이었음
  완전히 혼란스러웠음. 명령어는 수백 개였고 설명은 불투명했음. 레지스터가 무엇인지, 누산기가 무엇인지, 주소가 무엇인지, 스택이 무엇인지 전혀 몰랐음. David Rolfe가 내 Fortran 버전 Empire에 필요한 서브루틴을 몇 개 써 줘서 조금 도움이 됐지만 여전히 길을 잃은 상태였음
  어느 날 친구 Shal Farley에게 스택이 뭐냐고 물었더니, “접시 더미를 떠올려 봐. 접시를 하나 올리고(push), 하나를 꺼내는(pop) 거야”라고 했음. 그 순간 불이 켜진 듯 바로 이해됐음
  그 뒤 작은 보드의 6800 마이크로프로세서를 다루기 시작했음. 명령어가 40개쯤이고 카드 한 장에 다 들어갔음. 40개 명령어는 배우기 쉬웠고, 갑자기 모든 게 이해됐음
  다시 -10 매뉴얼로 돌아가자 모든 내용이 말이 되기 시작했음