spec: 640KB 셀프호스팅을 목표에서 내린다

철학 2의 근거가 사실과 달랐다. 전역 분석 금지만으로는 메모리가 줄지 않고,
현재 프론트엔드는 이미 그 예산을 한 자릿수 넘겼다 — FeBuild 하나가 26,892바이트
스택 지역 변수이고, 유닛 64개의 소스와 AST를 동시에 들고 있다.

전역 분석 금지는 국소적 진단과 작은 컴파일러라는 자체 근거로 유지한다.
컴파일러가 도는 곳을 §2.1로 분리했다. bits16 타깃은 그대로다 -- 8086용
프로그램을 만드는 것과 8086에서 컴파일러를 돌리는 것은 다른 일이다.

SPEC.md

@@ -11,7 +11,7 @@ DOS용 시스템 프로그래밍 언어. C만큼 빠르고, 메모리 안전성
 ## 1. 설계 철학
 
 1. **안전은 기본, 위험은 명시.** 기본 코드는 메모리 안전(널 역참조, 버퍼 오버런, use-after-free, 이중 해제 불가). 위험한 연산은 `unsafe {}` 블록 안에서만.
-2. **전역 분석 금지.** 모든 검사(타입, 소유권, 참조)는 함수 하나만 보고 완결되어야 한다. 이 제약이 라이프타임 표기를 없애고, 640KB 머신에서 셀프호스팅을 가능하게 한다.
+2. **전역 분석 금지.** 모든 검사(타입, 소유권, 참조)는 함수 하나만 보고 완결되어야 한다. 이 제약이 라이프타임 표기를 없애고, 진단을 위반 지점에 국소적으로 묶으며, 컴파일러를 작게 유지한다.
 3. **숨은 비용 없음.** 힙 할당, 복사, 소멸자 호출, 형변환이 전부 소스에 보인다. GC 없음, 예외 없음, 암묵 변환 없음.
 4. **읽히는 문법.** `이름: 타입` 순서, 좌→우 파싱, LL(1) 재귀하강으로 처리 가능.
 5. **작게 시작.** 기능을 넣기 전에 뺄 이유를 먼저 찾는다. 뺀 것과 그 대체 수단은 §11에 기록한다.
@@ -32,6 +32,20 @@ DOS용 시스템 프로그래밍 언어. C만큼 빠르고, 메모리 안전성
 - 소스 분기: `comptime if @bits == 16 { ... } else { ... }`
 - `bits32`에서 `far` 키워드를 쓰면 컴파일 에러.
 
+### 2.1 컴파일러 자신이 도는 곳
+
+위 표는 **생성되는 프로그램**의 타깃이다. 컴파일러 `fec`이 도는 곳은 별개이며 32비트
+보호모드 플랫이다 — 호스트에서든, DOS에서든 DPMI 익스텐더 위에서다. 당대의 Open
+Watcom 컴파일러 자신이 그렇게 돌았다.
+
+**8086 리얼모드에서 `fec`을 돌리는 것은 목표가 아니다.** 640KB는 8086의 한계가 아니라
+IBM PC가 1MiB 주소 공간의 위쪽 384KB를 하드웨어에 예약해서 생긴 것이고, 그 안에
+컴파일러를 넣으려면 AST를 통째로 들지 않는 스트리밍 구조와 오버레이가 필요하다.
+그것은 언어 설계가 아니라 컴파일러 구현 전략의 문제이므로 언어 명세에서 다루지 않는다.
+
+`bits16` 타깃은 유지된다. **8086용 프로그램을 만드는 것과 8086에서 컴파일러를 돌리는
+것은 다른 일이고, 전자만 명세의 약속이다.**
+
 ---
 
 ## 3. 어휘 구조
@@ -757,7 +771,7 @@ binding은 마지막 segment라 `io.write`, `mem.replace` 형태로 사용한다
 
 **등급 정의**
 - `영구` — §1 철학과 정면 충돌. v2.0에서도 넣지 않는다.
-- `구조적 불가` — 넣으면 R4를 풀어야 하고 전역 분석이 생겨 셀프호스팅 목표가 깨진다. 이 언어의 정의상 불가.
+- `구조적 불가` — 넣으면 R4를 풀어야 하고 전역 분석이 생긴다(§1 철학 2). 이 언어의 정의상 불가.
 - `v0.2` — 넣을 예정. 순서 문제일 뿐 원칙 위반 아님.
 - `편의` — 원칙 위반 없음, 구현도 쉬움. 여유 생기면 아무 때나.