어제 나는 AMD64 및 Itanium 타겟 용으로 컴파일 할 때 Microsoft Visual C++에서 인라인 어셈블리 (__asm 키워드 사용)가 지원되지 않는다는 것을 알게되었습니다.MSVC가 AMD64 및 Itanium 타겟의 인라인 어셈블리를 지원하지 않는 이유는 무엇입니까?
맞습니까? 그렇다면 왜 그 타겟에 대한 인라인 어셈블리를 지원하지 않는지 누구나 알 수 있습니까? 그것은 방금 큰 기능처럼 보이는 것입니다 ...
정확하지만, 그것은 여전히 VS 2010 Beta 1에서 지원되지 않습니다. 내 생각에 인라인 어셈블리는 구현하기가 너무 어렵습니다. Microsoft에서 구현 한 방식으로 주변 C 코드와 통합되어 데이터가 C 코드 안팎으로 흐를 수 있고 적절한 글루 코드가 자동으로 주입됩니다. 이를 위해 C 컴파일러는 실제로 어셈블러 코드를 이해해야합니다. AMD64 및 Itanium 용으로 구현되지 않았습니다.
그것은
그것은만큼 당신이 C 규칙을 따를 때, 어셈블러로 작성된 함수를 호출하는 것은 매우 쉽습니다 ... 그냥 드롭 오히려 큰 특징처럼 보인다. This tutorial은 어떻게 설명합니다.
동의 한, 유일한 실제 제약은 C와 ASM을 동일한 루틴에서 혼합 할 수 없다는 것입니다. 인라인 ASM 믹싱이 과학 코드에서 일반적으로 사용되는 파스칼 배경에서 오는 것처럼, 나는 언어를 다른 기능으로 분리하는 결정에 완전히 동의 할 수 있습니다. –
C 컴파일러는 중간에 ASM을 생성하므로 AMD64에서 인라인 ASM을 허용하는 것이 "어렵습니다". 인라인 ASM이 x86 용으로 지원되는 여러 컴파일러에서 x86_64 대상에 존재하지 않는 유일한 이유는 플랫폼 사양 때문입니다. –
@ MarkKCowan : MSVC의 인라인 ASM을 보았습니까? 그것은 무서운 많은 do-what-I-mean을 포함합니다. 어셈블리 코드 텍스트와 함께 C/C++ 변수를 자유롭게 혼합 할 수 있으므로 컴파일러는 모든 코드를 구문 분석해야하며 GCC의 방식과 달리 어셈블리 코드 자체가 printf와 유사한 스타일로 지정됩니다 (예 : 형식 문자열 및 입력, 출력 및 clobbered registers에 대한 명시 적 설명은 컴파일러에서 어셈블리를 분석 할 필요가 없도록합니다. 솔직히, 나는 GCC의 접근법을 선호한다. 왜냐하면 컴파일러를 덜 추측하기 때문이다. – SamB
@SamB 예, 델파이의 인라인 어셈블리와 동일합니다. 나는 GCC가 AT & T 문법을 사용하지 않기를 바란다. ( –