어셈블리는 타입이 없다는 통념이 틀린 이유

Odin의 인라인 어셈블리는 문자열 기반 탈출구가 아니라 프로시저처럼 호출하는 타입 검사 asm 템플릿으로, 다중 반환값과 상수·호출 규약을 호스트 언어 안에서 다룸 명령어마다 피연산자 종류·레지스터 클래스·폭·즉시값 범위·클로버가 정해져 있으므로, 어셈블리 자체를 명령어별 타입 시스템으로 보고 설계함 모든 ISA에 같은 문법을 적용하고 Intel식 목적지 우선 순서와 이름 기반 입출력, tie·pin·scratch·width-view 바인딩으로 레지스터 제약을 명시함 컴파일러는 core:rexcode의 검증된 인코딩 테이블로 명령어 형식과 효과를 검사하며, 잘못된 피연산자·범위 초과·누락되거나 불필요한 지시어를 소스 위치에서 진단함 제한된 위생적 매크로인 asm 템플릿은 전용 intrinsic 상당수를 읽고 검사할 수 있는 코드로 대체하며, 기반 테이블이 이미 준비돼 있어 문법 설계부터 LLVM IR 변환까지 약 7일이 걸림 문자열 기반 인라인 어셈블리의 한계 GCC식 확장 asm은 명령어 본문, "=r" 같은 제약 조건, %0·%1 같은 피연산자 참조를 모두 문자열과 위치 번호로 다룸 컴파일러는 본문의 타입과 의미를 거의 이해하지 못함 피연산자 번호를 사람이 직접 세어야 하며, 오류는 나중에 사용자가 작성하지 않은 생성 텍스트를 대상으로 어셈블러에서 발생함 이런 방식은 인라인 어셈블리를 언어 기능보다 탈출구로 먼저 설계한 결과임 호스트 언어의 타입 시스템, 호출 규약, 상수 시스템, 다중 반환값 의미론과 통합하지 않음 Odin의 인라인 어셈블리는 문자열을 전달하지 않고 언어의 일부로 처음부터 설계됨 앞선 언어와 컴파일러의 접근 MSVC MSVC의 __asm은 문자열이 아닌 문장 기반 블록이었고, C 변수와 레이블을 이름으로 직접 참조할 수 있었음 GCC식 제약 문자열이나 위치 번호가 필요하지 않았으며, 컴파일러가 C 식별자를 해석해 Windows 시스템 코드에서 널리 사용됨 구현은 x86 전용이어서 Microsoft가 x64와 ARM64로 옮겨갈 때 확장되지 않음 x64에서는 intrinsic을 사용하거나 별도 .asm 파일을 MASM으로 처리하도록 안내함 이름은 해석했지만 명령어의 의미까지 모델링하지 않았고, 명시적인 클로버 정보도 없어 최적화기가 블록 주변을 보수적으로 다뤘음 명령어가 수행하는 동작에 관한 의미론적 피드백도 제공하지 않았음 Turbo Pascal 초기 inline 지시어는 $FA, $90...