메타 얘기는 자제해야 하지만, 800쪽에 가까운 프로그래밍 예술서를 두고 왜 첫 홍보 문구, 저자의 도구 선택, 이 책으로 LLM을 학습시키면 벌어질 일만 50개 넘게 논하는지 모르겠음
샘플 장이나 1권을 실제로 읽은 사람의 평가가 더 궁금함

1권을 처음 받았을 때 발에 떨어뜨려 병원에 갔고 아직 다시 읽지는 못했지만, 저자의 예전 x86 어셈블리 책은 좋았음
Write Great Code 시리즈도 전반적으로 조언이 괜찮았으나, 컴파일러를 절대 믿지 말고 난해한 마법 같은 코드를 잔뜩 작성해 극한의 속도를 얻으라는 식의 내용도 많았음
그래도 2026년에 어셈블리를 배운다면 컴파일러를 불신하고 모든 것을 직접 하는 사람에게 배우는 것도 나쁘지 않음

예전 32비트 책은 꽤 괜찮았지만 Windows에 지나치게 집중했음
Linux용으로 적절한 문법을 쓰는 비슷한 책이 있으면 좋겠는데, 대응되는 책은 칠판 긁는 듯한 GAS 문법을 사용했음
요즘은 FASM이 훨씬 쓰기 좋은 반면 MASM은 Microsoft가 방치하고 있지만, 저자는 모든 작업에 MASM을 써 왔음

1권은 좋았지만 Ray Seyfarth의 책을 더 선호함
Windows를 거의 20년간 쓰지 않았고 2권은 이전 권보다 운영체제에 훨씬 종속적으로 보여 별로 관심이 가지 않음

이런 양상이 너무 많은 글에서 보여 우려됨
마케팅과 선전에서는 사람들이 맨 처음 접하는 것이 전체 논의의 분위기를 결정함
시작부터 모두가 엉뚱한 길로 빠지면 논의 전체와 궁극적으로 Hacker News의 유용성까지 떨어짐

1권은 실제로 매우 좋은 책이고 Randall Hyde는 이 분야의 훌륭한 저자임
HN은 예전과 많이 달라져 빈정거림과 허튼소리가 가득해졌고, AI를 두고 “LLM은 컴파일러와 똑같다”는 황당한 관점이 흔한 것도 그 연장선으로 보임
물론 모두가 그런 것은 아니며, 이 주제에 관심이 있다면 책을 차근차근 공부할 가치가 있음

요즘도 어셈블리 언어에 많은 시간을 들이는 사람이 있어 흥미롭고, 나 역시 최근 몇 년간 재미있게 다뤘음
LLVM 통합 어셈블러의 더 나은 프래그먼트와 수식·재배치 개선에 관한 글도 몇 편 작성했음 GNU Assembler는 MASM과 비교하면 while 반복문이나 strlen 같은 문자열 처리 기능이 많이 빠져 있음
MASM처럼 GAS도 기본적으로 이름에 의한 호출 평가를 사용하며, GAS의 altmacro 모드는 %(1+2) 같은 수식 평가를 지원하지만 절대 수식과 인수 위치로 엄격히 제한됨
반면 MASM의 % 연산자는 훨씬 범용적으로 보임

GNU assembler는 사람이 직접 쓰기보다 컴파일러 출력을 어셈블하는 데 목적이 있음
Linux에서 사람이 쓰는 표준적인 어셈블러는 nasm이며 다른 선택지도 있음
적지 않은 양의 어셈블리 코드를 작성한다면 방대한 상용구를 피할 수 있도록 포괄적인 매크로 라이브러리를 직접 만들거나 구해 두는 것이 필수임

“AI에게 시킬 수 있지만 불완전하고 형편없는 결과가 나온다”로 시작한 뒤 AI가 만든 듯한 글을 백여 단어나 이어 붙이는 구성은 구미가 당기지 않음
출판사 탓이기를 바라며, 저자가 직접 쓴 더 나은 문구로 교체했으면 함
다른 평가와 달리 어셈블리를 배우는 일은 지금도 의미가 있고, 업무가 덜 바빠지면 이 책이나 비슷한 책을 살 생각임

이 글은 AI가 생성한 글처럼 보이지 않음

MASM을 통해 16비트 x86으로 컴파일하는 컴파일러를 만들었기에 이 책이 자연스러운 다음 단계로 보이지만, 대신 선택할 만한 Linux용 책이 있는지 궁금함

어셈블리 책 제목치고는 이상함
대상이 Windows의 x64와 MASM으로 한정되지만, 다른 64비트 운영체제·CPU·어셈블러도 실제로 널리 사용됨

너무 성의 없는 평가처럼 보임
Randall은 ARM 어셈블리에 관한 대형 저서와 일반 소프트웨어 공학 서적도 여러 권 썼으니 다른 64비트 환경이 있다는 사실을 당연히 알고 있음 The Art of Assembly라는 제목은 오래전부터 이어졌고, 이 x64판은 최신 개정판임
이전 판은 사실상 작은 언어를 이루는 MASM 매크로 집합인 “고수준 어셈블리”를 도입하고 집중했는데, 이번 책은 그보다 훌륭함
x86/64 어셈블리에 조금이라도 관심이 있다면 AoA를 알고 있을 가능성이 큼

이전 책들과 제목의 일관성을 유지한 결과임
이번 판의 플랫폼 범위는 매우 좁지만, 일반 어셈블리 책도 결국 특정 플랫폼을 선택하고 독자가 배운 기술을 다른 환경에 적용하기를 기대할 수밖에 없음

x64 Windows는 여전히 널리 쓰이므로 그리 이상하지 않음
Windows 개발자라면 대개 Visual Studio와 MASM을 설치하게 되며, JWASM이나 UASM 같은 오픈 소스 MASM 호환 어셈블러도 선택할 수 있음
물론 Linux/BSD, NASM/FASM, ARM 등을 선호할 수도 있음

고수준 코드의 병목 함수만 최적화하는 수준이 아니라 실제 소프트웨어를 어셈블리로 작성한다면, 내 경험상 MASM이 가장 편한 도구임

수십 년 전 이 책의 구판으로 보호 모드 어셈블리를 배웠고, 당시에도 더 오래된 16비트판이 있었던 것으로 기억함
저자가 아직도 책을 개정한다니 놀라움

지금은 이런 책이 어느 때보다 필요함
AI는 사람을 게으르게 만들어 내부 동작 원리를 잊게 하므로, 계속 호기심을 갖고 질문하지 않으면 쏟아지는 AI 생성 코드를 이해할 수 없게 됨

MASM이라니, 멋진 사람들은 모두 NASM이나 YASM을 씀

적어도 HLA나 GAS는 아님
1990년대 어셈블리 프로그래머들이 MASM, TASM, RosAsm, HLA 진영으로 나뉘어 벌이던 논쟁은 Chrysler, Ford, GM 지지자들의 싸움과 꽤 비슷했으며, 당시 GAS를 진지하게 보는 사람은 거의 없었음

아직도 FASM을 좋아하는 사람도 있는데, 왜 NASM이나 YASM이어야 하는지 궁금함

Linux 커널은 C 전처리기와 함께 GAS 또는 clang을 선호함
다행히 clang의 어셈블러 단위 테스트와 LLVM MC 계층의 단위 테스트도 대부분 GAS식 문법을 사용함

MASM은 쉽게 구할 수 없는 도구라는 데 동의함

TASM을 씀

“Windows가 실제로 기대하는 가상 함수 테이블 구조”라는 표현이 있는데, 가상 함수 테이블 배치가 사용자 공간과 커널 사이 ABI의 일부인지 궁금함

주요 커널 ABI는 모두 C 함수 인터페이스를 안정 ABI로 사용함
예외적으로 Linux는 어셈블리 시스템 호출 명령을 안정 인터페이스로 쓰지만, 구조체나 스택 배치에는 여전히 부수적인 C ABI가 필요함
C++에는 사실상 MSVC ABI와 Itanium ABI라는 2.5개의 주요 ABI가 있음
MSVC와 호환하려는 clang은 MSVC ABI를 쓰고 나머지는 Itanium ABI를 사용함
나머지 0.5는 ARM의 예외 처리 테이블 배치 차이와, 64비트 포인터 대신 32비트 오프셋을 쓰는 압축 가상 함수 테이블 옵션 같은 변형임
Windows COM API는 커널이 아닌 사용자 공간 라이브러리이며, C++ 가상 함수 테이블과 직접 호환되도록 설계된 IDL에 의존함
다만 함수 오버로딩과 가상 상속을 쓰지 않는 제한된 C++ 부분집합이라 모든 ABI가 사실상 같은 합리적 배치를 사용함

이는 커널 ABI가 아니라 MSVC x64 ABI의 일부임
커널과 사용자 모드 Win32 API는 모두 C 연결 규약을 사용하므로 가상 함수 테이블과 무관하며, ABI는 운영체제가 아닌 컴파일러의 규약임
그래도 Windows에서 실행되는 소프트웨어라면 현실적으로 MSVC ABI를 사용할 가능성이 큼

Windows가 아닌 환경에서는 Itanium ABI, Windows에서는 MSVC ABI를 따르면 됨
자체 컴파일러가 완전히 독자적인 규약을 구현할 수도 있지만 그 경우 자기 자신과만 호환됨