Odin의 인라인 어셈블리: 모든 언어 중 최고라고 주장하는 이유
Everyone says assembly is untyped—everyone is wrong
Odin 언어의 창시자가 자신의 인라인 어셈블리 설계가 왜 최고인지 설명한다. 기존의 문자열 기반 어셈블리(GCC, Clang)와 달리, Odin은 어셈블리를 타입 시스템과 통합하여 완전한 타입 검사를 수행한다. 어셈블리가 실제로 타입이 있다는 통찰을 바탕으로, 모든 ISA에 일관된 문법을 제공하며, MSVC와 Turbo Pascal의 한계를 극복했다. 7일 만에 구축된 이 시스템은 clobber, pinned, tied, scratch 레지스터 바인딩과 의미론적 진단을 지원한다.
어셈블리는 사실상 다항(polyadic) 타입 대수이며, 모두가 바이트 수프인 척 하기로 동의한 것이다.
HN 토론
90- amluto
이 기사는 실제로 저자의 프로그래밍 언어 Odin을 위해 개발된 인라인 어셈블리 문법에 관한 것입니다 (그리고 확실히 TAL, 타입드 어셈블리 언어에 관한 것은 아닙니다). 여기에는 흥미로운 아이디어가 많이 있습니다.
그러나 제 비판 중 하나는 주류 범용 CPU 아키텍처가 얼마나 유사해졌는지 지적하는 것입니다. 그들은 모두 C 머신입니다. 이는 컴파일러 측면의 복잡성을 급격히 단순화하며, 저자가 amd64와 aarch64를 대상으로 하는 것으로 보입니다. 컴파일러를 rv64로 확장하는 것은 아마 간단할 것입니다.
저는 Odin이나 그 컴파일러 구현에 대해 아는 바가 없지만, 그 언어가 C 머신 모델과 일치하는 기계 관점을 따른다고 상상합니다. 더 난해한 언어를 상상해 보면, 컴파일러는 아마 C 머신 모델과 일치하는 중간 언어가 필요할 것이며, 인라인 어셈블리는 객체 코드로 더 낮춰지기 전에 중간 표현으로의 멱등적 하향 변환을 견뎌야 할 것입니다. 이러한 세부 사항이 제가 정말로 궁금하고 아마 가장 지적으로 자극적인 부분입니다.
가장 흥미로운 가능성은 Odin 컴파일러 자체가 전적으로 Odin으로 작성된 경우입니다. 만약 그렇다면, 그것은 인라인 어셈블리 문법의 힘을 정말로 보여줄 것입니다. 제가 아는 한, 다중 명령어 아키텍처를 대상으로 하면서 이 각도를 추진한 최적화 컴파일러는 없었습니다. 제 기억이 맞다면, Plan9 C 컴파일러조차도 일부 기본 최적화를 일반화 단계로 옮겼습니다.
- WalterBright
저는 사용자 정의 문법에 대해 매우 엇갈린 의견을 가지고 있습니다. 제 생각에 올바른 asm 문법은 (극히 드문 예외를 제외하고) 매뉴얼에 있는 것입니다. 이것이 Intel 문법이 옳고 AT&T 문법이 틀린 이유입니다: ISA는 Intel에서 나왔고, 문서는 Intel과 AMD에서 나왔으며, 그 문서들은 Intel 문법을 사용합니다.
그래서 저는 사용자 정의 문법이 적어도 Fil-C만큼 강력한 검사기를 결과적으로 제공하기를 바랐습니다. 아마도 'xyz를 clobber한 것처럼 보이지만, 실제로는 그렇지 않다고 약속합니다'라고 말할 수 있는 탈출구가 있을 것입니다.
안타깝게도, 기사의 CPUID 예제는 분명히 컴파일되지만, 제 생각에는 컴파일되지 않아야 합니다: CPUID는 EAX와 ECX의 두 입력을 받는데, 예제는 ECX를 입력으로 바인딩하는 것을 잊었습니다. VM에서 특별한 작업을 하는 경우 CPUID가 더 많은 입력을 받는다고 주장할 수도 있지만, ECX는 정말로 매우 명확합니다.