BITS는 생성할 바이트를 정합니다
NASM의 BITS 16·32·64는 어셈블러가 사용할 명령 인코딩 문맥을 선택합니다. CPU의 CR0·CR4·EFER나 CS를 직접 바꾸는 명령이 아닙니다. 실행할 때는 CPU의 모드와 코드 세그먼트 속성이 그 바이트를 어떻게 해석할지 결정하므로, BITS 32만 쓴다고 16비트 실행 문맥에서도 모든 코드가 옳게 실행된다고 볼 수 없습니다.
16비트 코드에서 일부 32비트 피연산자·주소 형식을 쓴다고 해서 CPU 실행 모드가 바뀌는 것도 아닙니다. prefix가 바꾸는 크기를 실제 명령 바이트와 함께 확인해야 합니다. GNU assembler의 .code16 역시 출력 인코딩 설정이지 모드 전환 절차가 아닙니다.
·이 ResetVector는 32비트 상태에서 먼저 SEC를 찾습니다
edk2-stable202508의 UefiCpuPkg/ResetVector/Vtf0/Main.asm은 16비트 초기 처리 뒤 TransitionFromReal16To32BitFlat을 호출하고, 32비트 코드에서 부팅 펌웨어 볼륨과 SEC 진입점을 검색합니다. IA32 빌드는 여기서 SEC로 분기합니다. X64 빌드는 64비트 전환을 마친 뒤 SEC로 분기합니다. 32비트 경유를 단 한 명령의 형식적인 통과라고 설명하면 이 검색 작업을 놓칩니다.
16비트 초기 처리 → GDT·보호 모드 전환
32비트 flat 실행 → BFV와 SEC 진입점 검색
IA32: SEC로 분기 / X64: 64비트 전환 뒤 SEC로 분기
IA-32e 활성화와 64비트 코드 진입을 구분합니다
같은 태그의 Flat32ToFlat64.asm은 페이지 테이블 기준 주소를 준비하고 CR4.PAE, EFER.LME, CR0.PG를 설정한 뒤 64비트 코드 세그먼트로 far jump합니다. 필요한 페이지 테이블과 CPU 지원, 기존 실행 상태가 맞아야 하는 절차입니다. 레지스터 비트만 순서 없이 켜면 되는 일반 레시피가 아닙니다.
IA-32e 모드 안에서도 CS의 L 비트가 1인 64비트 코드와 L 비트가 0인 compatibility mode를 구분합니다. 64비트 코드 세그먼트의 D 비트는 0이어야 합니다. EFER.LME는 활성화를 요청하는 설정일 뿐이므로, LME를 켰다고 해서 활성 상태인 LMA나 현재 CS의 속성까지 정해지는 것은 아닙니다.
·소스 경로를 모든 플랫폼의 부팅 순서로 일반화하지 않습니다
이 설명은 해당 태그의 Vtf0 경로에 한정합니다. 다른 ResetVector 구현이나 가상 머신의 시작 계약은 다를 수 있습니다. 분석할 때는 빌드 아키텍처, 실제 선택된 파일, 현재 모드와 CS, 페이지 테이블, 마지막 분기 목적지를 함께 기록합니다.
기존 U-Boot의 CAR·global data 초기화와 Linux 압축 커널 진입은 다른 코드 경로입니다. 여기서는 고정 소스와 명령 인코딩 문서를 대조했으며 펌웨어를 빌드하거나 보드에서 실행하지 않았습니다. Intel 매뉴얼 전체를 읽었다는 주장도 하지 않습니다.