Rust: 'asm'에 대한 추적 문제(인라인 어셈블리)

안정적인 코드에서 인라인 어셈블리의 하위 호환성을 보장하는 데 어려움이 있습니까?

@main-- https://github.com/rust-lang/rfcs/pull/1471#issuecomment -173982852에 훌륭한 의견이 있습니다. 내가 후손을 위해 여기에서 재현하고 있습니다.

와 모든 열린 버그 및 불안정성 주변 은 ASM을 ()! (거기에 많은 , 정말이 안정화를위한 준비가 생각하지 않습니다) - 나는 녹 안정적인 인라인 어셈블리를 사랑 했음에도 불구하고.

우리는 또한 오늘날의 asm!()이 정말 최고의 솔루션인지 또는 RFC #129 또는 D 의 라인을 따르는 것이 더 나은지 논의해야 합니다. 여기서 고려해야 할 한 가지 중요한 점은 asm()이 gcc와 동일한 제약 조건 집합을 지원하지 않는다는 것입니다. 따라서 다음 중 하나를 수행할 수 있습니다.

• LLVM 동작을 고수하고 이에 대한 문서를 작성하십시오(찾을 수 없었기 때문에). Rustc의 복잡성을 피하기 때문에 좋습니다. C/C++에서 온 프로그래머를 혼란스럽게 하고 일부 제약 조건은 Rust 코드에서 에뮬레이트하기 어려울 수 있기 때문에 좋지 않습니다.
• gcc를 에뮬레이트 하고 문서에 링크하기만 하면 됩니다. 많은 프로그래머가 이미 이것을 알고 있고 약간의 수정으로 복사하여 붙여넣을 수 있는 예제가 많기 때문에 좋습니다. 컴파일러에 대한 중요하지 않은 확장이기 때문에 좋지 않습니다.
• 다른 일을 하십시오(D가 하는 것과 같이): 성과가 있을 수도 있고 없을 수도 있는 많은 일. 올바르게 수행되면 인체 공학 측면에서 gcc 스타일보다 훨씬 우수할 수 있으며 불투명한 얼룩보다 언어 및 컴파일러와 더 잘 통합될 수 있습니다. .

마지막으로 고려해야 할 또 다른 사항은 현재 디자인에서 인라인 asm에 상당히 의존하거나 인라인 asm이 올바르게 수행되는 #1201 입니다.

개인적으로 MSVC x64에서 Microsoft가 수행한 작업을 수행하는 것이 더 낫다고 생각합니다. 각 asm 명령에 대해 (거의) 포괄적인 내장 함수 세트를 정의하고 해당 내장 함수를 통해서만 "인라인 asm"을 수행합니다. 그렇지 않으면 인라인 asm을 둘러싼 코드를 최적화하기가 매우 어렵습니다. 이는 인라인 asm의 많은 사용이 성능 최적화를 위한 것이기 때문에 아이러니합니다.

본질적 기반 접근 방식의 한 가지 장점은 그것이 전부 아니면 전무일 필요가 없다는 것입니다. 가장 필요한 내장 함수를 먼저 정의하고 점진적으로 설정을 구축할 수 있습니다. 예를 들어 암호화의 경우 _addcarry_u64 , _addcarry_u32 있습니다. 본질적인 작업을 수행하는 작업은 이미 철저하게 완료된 것으로 보입니다: https://github.com/huonw/llvmint.

또한 내장 함수를 사용하는 것이 훨씬 더 편리하기 때문에(C 및 C++에서 사용한 경험을 기반으로) 궁극적으로 인라인 asm을 지원하기로 결정한 경우에도 내장 함수를 추가하는 것이 좋습니다. 우리가 어디까지 도달했는지는 잘못될 위험이 전혀 없는 것처럼 보입니다.

내장 함수도 좋지만 asm! 는 명령어를 삽입하는 것 이상의 용도로 사용할 수 있습니다.
예를 들어, probe 상자에서 ELF 메모를 생성하는 방법을 참조하십시오.
https://github.com/cuviper/rust-libprobe/blob/master/src/platform/systemtap.rs

그런 종류의 해커가 드물지 않을까 생각하지만 여전히 지원하는 데 유용하다고 생각합니다.

@briansmith

인라인 asm은 자체 레지스터/스택 할당(예: 네이키드 함수)을 수행하려는 코드에도 유용합니다.

@briansmith 예, 가능한 경우 내장 기능을 사용해야 하는 몇 가지 훌륭한 이유입니다. 그러나 궁극적인 탈출 해치로 인라인 어셈블리를 사용하는 것이 좋습니다.

@briansmith asm!() 는 내장 함수의 _종류_입니다. 전자를 사용하여 후자를 빌드할 수 있기 때문입니다. (이 추론에 반대하는 일반적인 주장은 컴파일러가 이론적으로 내장 함수를 _through_ 최적화할 수 있다는 것입니다. 예를 들어 루프에서 끌어올리고, 그에 대해 CSE를 실행하는 등입니다. 그러나 _optimization_ 목적으로 asm을 작성하는 사람이 더 나은 작업을 수행할 것이라는 것은 꽤 강력한 반대입니다. 어쨌든 컴파일러보다.) https://github.com/rust-lang/rust/issues/29722#issuecomment -207628164 및 https://github.com/rust-lang/rust/issues/29722# 도 참조 하십시오. inline asm은 작동하지만 내장은 작동하지 않는 경우 issuecomment -207823543입니다.

반면에 내장 함수는 손으로 굴린 asm 구현으로 얻을 수 있는 _적어도_ 성능을 달성하기 위해 "충분히 똑똑한 컴파일러"에 크게 의존합니다. 이에 대한 나의 지식은 구식이지만 상당한 진전이 없는 한 내장 기반 구현은 대부분은 아니지만 많은 경우에서 여전히 측정 가능하게 열등합니다. 물론 그것들은 사용하기가 훨씬 더 편리하지만 프로그래머가 특정 CPU 명령어의 세계로 기꺼이 내려가려고 할 때 _그것_에 대해 별로 신경 쓰지 않는다고 말하고 싶습니다.

이제 또 다른 흥미로운 고려 사항은 내장 기능이 지원되지 않는 아키텍처에서 대체 코드와 결합될 수 있다는 것입니다. 이것은 두 가지 장점을 모두 제공합니다. 코드는 여전히 이식 가능합니다. 하드웨어가 지원하는 일부 하드웨어 가속 작업을 사용할 수 있습니다. 물론 이것은 매우 일반적인 지침이나 애플리케이션에 하나의 분명한 대상 아키텍처가 있는 경우에만 실제로 효과가 있습니다. 이제 내가 이것을 언급하는 이유는 이것이 _compiler-provided_ 내장 함수를 사용하여 잠재적으로 _바람직하지 않은_ 일 수 있다고 주장할 수 있기 때문입니다. 내장 기능이 _library_에서 제공되는 경우(그리고 인라인 asm을 사용해서만 구현되는 경우) 다른 이야기라고 할 수 있습니다. 사실, 인라인 asm보다 내장 기능을 더 많이 사용하는 제 자신을 볼 수 있지만 이것이 제가 선호하는 큰 그림입니다.

(RFC #1199 의 내장 함수는 대부분 SIMD를 작동시키기 위해 존재하므로 이 논의와 다소 직교한다고 생각합니다.)

@briansmith

그렇지 않으면 인라인 asm을 둘러싼 코드를 최적화하기가 매우 어렵습니다. 이는 인라인 asm의 많은 사용이 성능 최적화를 위한 것이기 때문에 아이러니합니다.

무슨 말인지 잘 모르겠습니다. 컴파일러가 asm을 개별 작업으로 분해하여 강도 감소 또는 엿보기 최적화를 수행할 수 없는 것은 사실입니다. 그러나 GCC 모델에서는 최소한 컴파일러가 사용하는 레지스터를 할당하고, 코드 경로를 복제할 때 복사하고, 사용하지 않는 경우 삭제하는 등의 작업을 수행할 수 있습니다. asm이 휘발성이 아닌 경우 GCC는 fsin 와 같은 다른 불투명 작업처럼 처리하기에 충분한 정보를 가지고 있습니다. 이상한 디자인의 전체 동기는 인라인 asm을 최적화 프로그램이 엉망으로 만들 수 있도록 하는 것입니다.

그러나 나는 그것을 많이 사용하지 않았습니다. 특히 최근에는 그러하지 않았습니다. 그리고 저는 LLVM의 기능 표현에 대한 경험이 없습니다. 그래서 그동안 제가 뭘 잘못 이해했는지, 뭐가 달라졌는지 궁금합니다.

no_std 생태계 에 대한 @japaric 의 설문조사 에서 asm! 매크로가 가장 일반적으로 사용되는 기능 중 하나로 포함되어 있기 때문에 최근 작업 주에 이 문제에 대해 논의했습니다. 불행히도 우리는 이 기능을 안정화할 수 있는 쉬운 방법을 찾지 못했지만 이 모든 것을 잊지 않기 위해 메모를 적어두고 싶었습니다.

• 첫째, 현재 asm! 매크로에서 허용되는 구문에 대한 훌륭한 사양이 없습니다. 지금은 일반적으로 훌륭한 문서가 없는 "gcc를 보세요"라고 말하는 "클랭을 보세요"라고 말하는 "LLVM을 보세요"로 끝납니다. 결국 이것은 일반적으로 "다른 사람의 예제를 읽고 적용" 또는 "LLVM의 소스 코드 읽기"로 끝납니다. 안정화를 위해 최소한의 구문 및 문서 사양이 필요합니다.

• 현재 우리가 아는 한 LLVM의 안정성 보장은 없습니다. asm! 매크로는 LLVM이 현재 수행하는 작업에 대한 직접 바인딩입니다. 이것은 우리가 원할 때 LLVM을 여전히 자유롭게 업그레이드할 수 있음을 의미합니까? LLVM은 이 구문을 절대 위반하지 않을 것이라고 보장합니까? 이 문제를 완화하는 방법은 LLVM의 구문으로 컴파일되는 자체 계층을 갖는 것입니다. 그렇게 하면 원할 때마다 LLVM을 변경할 수 있고 LLVM의 인라인 어셈블리 구현이 변경되면 LLVM 구문으로 번역을 업데이트할 수 있습니다. asm! 가 안정화되려면 기본적으로 Rust에서 안정성을 보장 하는 메커니즘이 필요합니다.

• 현재 인라인 어셈블리와 관련된 버그가 꽤 있습니다. A-inline-assembly 태그는 좋은 출발점이며 현재 ICE, LLVM의 segfaults 등이 산재해 있습니다. 전반적으로 오늘날 구현된 이 기능은 다른 사람들이 안정적인 Rust의 기능.

• 인라인 어셈블리를 안정화하면 대체 백엔드 구현이 매우 어려울 수 있습니다. 예를 들어 미리 또는 크레인 리프트와 같은 백엔드는 구현에 따라 LLVM 백엔드와 기능 패리티에 도달하는 데 매우 오랜 시간이 걸릴 수 있습니다. 이것은 여기서 수행할 수 있는 작업의 작은 부분이 있음을 의미할 수 있지만 인라인 어셈블리 안정화를 고려할 때 염두에 두어야 할 중요한 사항입니다.

우리 위에 나열된 문제에도 불구하고 적어도 앞으로이 문제를 이동하는 몇 가지 능력을 멀리 온에 반드시 싶어! 이를 위해 우리는 인라인 어셈블리를 안정화 방향으로 조금씩 움직일 수 있는 방법에 대한 몇 가지 전략을 브레인스토밍했습니다. 앞으로의 주요 방법은 clang이 하는 일을 조사하는 것입니다. 아마도 clang과 C는 효과적으로 안정적인 인라인 어셈블리 구문을 가지고 있으며 clang이 하는 모든 일(특히 wrt LLVM)을 미러링할 수 있습니다. clang이 인라인 어셈블리를 구현하는 방법을 더 깊이 이해하는 것이 좋습니다. clang에는 자체 번역 레이어가 있습니까? 입력 매개변수의 유효성을 검사합니까? (등)

앞으로 나아가기 위한 또 다른 가능성은 이미 안정적인 다른 곳에서 선반을 제거할 수 있는 어셈블러가 있는지 확인하는 것입니다. 여기에 있는 몇 가지 아이디어는 nasm 또는 plan9 어셈블러였습니다. LLVM의 어셈블러를 사용하면 IR의 인라인 어셈블리 명령과 동일한 안정성 보장 문제가 있습니다. (가능하지만 사용하기 전에 안정성 보장이 필요합니다)

LLVM의 인라인 asm 구문이 clang/gcc에서 사용되는 구문과 다르다는 점을 지적하고 싶습니다. 차이점은 다음과 같습니다.

• LLVM은 사용 $0 대신 %0 .
• LLVM은 명명된 asm 피연산자 %[name] 지원하지 않습니다.
• LLVM은 다른 레지스터 제약 조건 유형을 지원합니다 예를 들어 "{eax}" 대신 "a" 86에.
• LLVM은 명시적 레지스터 제약 조건( "{r11}" )을 지원합니다. C에서는 값을 레지스터( register asm("r11") int x )에 바인딩하기 위해 레지스터 asm 변수를 대신 사용해야 합니다.
• LLVM "m" 및 "=m" 제약 조건은 기본적으로 깨졌습니다. Clang은 이를 간접 메모리 제약 "*m" 및 "=*m" 로 변환하고 변수 자체 대신 LLVM에 변수 주소를 전달합니다.
• 등...

Clang은 인라인 asm을 LLVM에 전달하기 전에 gcc 형식에서 LLVM 형식으로 변환합니다. 또한 제약 조건의 일부 유효성 검사를 수행합니다. 예를 들어 "i" 피연산자가 컴파일 타임 상수인지 확인합니다.

이에 비추어 나는 우리가 clang이 수행하는 것과 동일한 번역 및 유효성 검사를 구현하고 이상한 LLVM 대신 적절한 gcc 인라인 asm 구문을 지원해야 한다고 생각합니다.

온라인 슬라이드 가 포함된 D, MSVC, gcc, LLVM 및 Rust 요약에 대한 훌륭한 비디오 가 있습니다.

안정적인 Rust에서 인라인 ASM을 사용하고 싶고 Rust의 LLVM MC API에 액세스하려고 하는 것보다 더 많은 경험이 있는 사람으로서 다음과 같은 생각이 듭니다.

• 인라인 ASM은 기본적으로 일부 문자열 대체 후 어셈블을 위해 출력 .s 파일에 코드 조각을 복사하여 붙여넣는 것입니다. 또한 입력 및 출력 레지스터와 클로버 레지스터가 첨부되어 있습니다. 이 기본 프레임워크는 LLVM에서 실제로 변경될 가능성이 거의 없으며(일부 세부 사항은 약간 다를 수 있음) 이것이 상당히 프레임워크 독립적인 표현이라고 생각합니다.

• Rust 지향 사양에서 LLVM 지향 IR 형식으로 변환을 구성하는 것은 어렵지 않습니다. 그리고 LLVM의 $ 및 GCC의 % 표기법과 달리 형식 지정을 위한 rust {} 구문은 어셈블리 언어를 방해하지 않는 것이 좋습니다.

• LLVM은 특히 LLVM에 의해 생성되지 않은 명령어에서 어떤 레지스터가 클로버링되는지 실제로 식별하는 실제로 놀랍게도 나쁜 작업을 수행합니다. 이것은 사용자가 클로버링되는 레지스터를 수동으로 지정하는 것이 거의 필요하다는 것을 의미합니다.

• 어셈블리를 직접 구문 분석하는 것은 악몽일 것입니다. LLVM-C API는 MCAsmParser 논리를 노출하지 않으며 이러한 클래스는 bindgen으로 작업하는 데 상당히 성가십니다(제가 완료했습니다).

• 다른 백엔드로의 이식성을 위해 인라인 어셈블리를 대부분 "이 문자열을 약간의 레지스터 할당 및 문자열 대체로 복사하여 붙여넣기" 수준으로 유지하는 한 백엔드를 그렇게 많이 억제하지 않아야 합니다. 정수 상수 및 메모리 제약 조건을 삭제하고 레지스터 뱅크 제약 조건만 유지하면 문제가 발생하지 않습니다.

나는 절차적 매크로로 무엇을 할 수 있는지 알아보기 위해 약간의 플레이를 했습니다. GCC 스타일 인라인 어셈블리를 Rust 스타일 https://github.com/parched/gcc-asm-rs 로 변환하는 것을 작성했습니다

그래서 저는 녹이 기본 빌딩 블록을 안정화시켜야 한다고 생각하고 커뮤니티가 매크로를 사용하여 트리 밖으로 반복하여 최상의 솔루션을 찾아낼 수 있다고 생각합니다. 기본적으로 "r" 및 "i" 및 아마도 "m" 제약 조건만 사용하고 클로버 없이 현재 가지고 있는 llvm 스타일을 안정화하십시오. 다른 제약 및 클로버는 나중에 자체 미니 RFC 유형으로 안정화될 수 있습니다.

개인적으로 저는 이 기능을 안정화하는 것이 누군가가 1년 내내 이 작업을 수행할 정규직 전문 계약자를 고용하지 않는 한 결코 수행할 수 없는 일종의 대규모 작업이라고 느끼기 시작했습니다. asm! 를 안정화하자는 @parched 의 제안이 이것을 다루기 쉽게 만들 것이라고 믿고 싶습니다. 누군가가 그것을 집어 들고 실행되기를 바랍니다. 그러나 그렇지 않다면 결코 도착하지 않을 만족스러운 솔루션에 도달하려는 시도를 중단하고 다음과 같은 불만족스러운 솔루션에 도달해야 합니다. asm! 그대로, 사마귀, ICE, 버그 및 모든 것을 안정화 , 버벅임과 비 이식성을 광고하는 문서에서 밝고 대담한 경고와 함께 만족스러운 구현이 하늘의 호스트에 기적적으로 내려오면 언젠가는 사용하지 않을 의도로. IOW, 우리는 우리가 macro_rules! 대해 한 일을 정확히 해야 합니다(물론 macro_rules! 처럼, 우리는 짧은 기간 동안 미친 듯이 반창고를 하고 누출되는 미래를 대비할 수 있습니다). 대체 백엔드에 대한 결과가 안타깝지만 시스템 언어가 인라인 어셈블리를 그러한 림보로 분류하는 것은 부끄러운 일이며 여러 백엔드의 가상 가능성이 실제로 사용 가능한 하나의 백엔드의 존재를 계속 방해하도록 할 수 없습니다. 내가 당신에게 간청합니다, 내가 틀렸다는 것을 증명하십시오!

시스템 언어가 인라인 어셈블리를 그런 림보로 격하하는 것은 부끄러운 일입니다.

데이터 포인트로서, 저는 안정적인 Rust로 일부 asm을 방출하기 위한 유일한 목적으로 gcc 에 의존하는 상자에서 작업하고 있습니다: https://github.com/main--/unwind- rs/blob/266e0f26b6423f4a2b8a8c72442b319b5c33b658/src/unwind_helper.c

확실히 장점이 있지만 "구성 요소를 안정화하고 나머지는 매크로 매크로에 맡기는" 접근 방식에 대해 약간 조심스럽습니다. 기본적으로 설계, RFC 및 구현 프로세스를 작업을 수행하려는 사람에게 아웃소싱합니다. 물론 안정성/품질 보증이 약한 것이 요점입니다(절충안은 불완전한 것이 없는 것이 아예 없는 것보다 훨씬 낫다는 것입니다).

최소한 빌딩 블록은 잘 설계되어야 합니다. 제 생각에는 "expr" : foo : bar : baz 확실히 그렇지 않습니다. 첫 번째 시도에서 주문을 제대로 받은 기억이 없고 항상 찾아봐야 합니다. "마법 범주를 콜론으로 구분하여 마법 문자로 상수 문자열을 지정하여 변수 이름에 마법 같은 일을 하게 하고 어떻게든 거기에 매쉬"하는 것은 좋지 않습니다.

하나의 아이디어, …

오늘날에는 x64 코드의 한 가지 버전으로 어셈블리를 사전 처리하는 데 사용되는 플러그인으로 어셈블리 코드를 생성하는 데 도움이 될 수 있는 dynasm이라는 프로젝트가 이미 있습니다.

이 프로젝트는 인라인 어셈블리의 문제에 대한 답은 아니지만 확실히 도움이 될 수 있습니다. 만약 rustc가 변수를 레지스터에 매핑하는 방법을 제공하고 코드에 바이트 세트를 삽입하는 것을 허용한다면 그러한 프로젝트는 다음을 채우는 데에도 사용될 수 있습니다. 이 바이트 집합을 올립니다.

이런 식으로, Rustc 관점에서 필요한 유일한 표준화 부분은 생성된 코드에 바이트 시퀀스를 삽입하고 특정 레지스터 할당을 적용하는 기능입니다. 이렇게 하면 특정 언어 버전에 대한 모든 선택 사항이 제거됩니다.

역동성이 없더라도 이것은 cpuid / rtdsc 명령어에 대한 매크로를 만드는 방법으로 사용될 수도 있습니다. 이 매크로는 원시 바이트 시퀀스로 변환됩니다.

다음 질문은 바이트 시퀀스에 추가 속성/제약 조건을 추가하려는 경우일 수 있습니다.

[편집: 나는 이 댓글에서 내가 말한 모든 것이 옳다고 생각하지 않습니다.]

LLVM의 통합 어셈블러를 계속 사용하려는 경우(외부 어셈블러를 생성하는 것보다 빠르다고 가정), 안정화란 LLVM의 인라인 어셈블리 표현식 및 통합 어셈블러 지원이 정확히 무엇인지에 대해 안정화하고 변경 사항이 발생할 경우 이를 보상하는 것을 의미합니다.

외부 어셈블러를 생성하려는 경우 원하는 구문을 사용할 수 있지만 통합 어셈블러의 이점을 무시하고 호출하는 외부 어셈블러의 변경 사항에 노출됩니다.

Clang에서도 그렇게 하지 않는데 LLVM의 형식으로 안정화하는 것이 이상할 것이라고 생각합니다. 아마도 내부적으로 LLVM의 지원을 사용하지만 GCC와 같은 인터페이스를 제공합니다.

특히 AFAIK Clang의 입장이 "Clang은 GCC가 지원하는 것을 정확히 지원합니다"이기 때문에 "Rust는 Clang이 지원하는 것을 정확히 지원합니다"라고 말하는 것이 100% 괜찮습니다. 실제 Rust 사양이 있다면 언어를 "인라인 어셈블리는 구현 정의"로 부드럽게 할 수 있습니다. 우선 순위 및 사실상의 표준화는 강력한 도구입니다. GCC 구문을 LLVM으로 변환하기 위해 Clang의 자체 코드를 재사용할 수 있다면 더욱 좋습니다. 대안적인 백엔드 문제는 사라지지 않지만 이론적으로 GCC에 대한 Rust 프론트엔드는 그다지 짜증나지 않을 것입니다. 우리가 설계해야 하는 일도, 끝없이 자전거를 몰고 가야 하는 일도 적고, 가르쳐야 하는 일도 적고, 유지 관리해야 하는 일도 적습니다.

clang이 지원하는 측면에서 정의된 것을 안정화하면 clang_asm! 라고 해야 합니다. asm! 이름은 다른 주요 Rust 기능과 마찬가지로 전체 RFC 프로세스를 통해 설계된 것을 위해 예약해야 합니다. #자전거보관소

Rust 인라인 어셈블리에서 보고 싶은 몇 가지 사항이 있습니다.

• 템플릿이 있는 대체 패턴은 보기 흉합니다. 나는 항상 어셈블리 텍스트와 제약 목록 사이를 왔다갔다 합니다. 간결함은 사람들이 위치 매개변수를 사용하도록 권장하여 가독성을 떨어뜨립니다. 기호 이름은 종종 템플릿에서 피연산자 이름 지정 및 피연산자에 바인딩되는 표현식에서 동일한 이름이 세 번 반복된다는 것을 의미합니다. Alex의 코멘트 에서 언급한 슬라이드는 D와 MSVC를 사용하여 코드에서 변수를 단순히 참조할 수 있다는 것을 보여줍니다. 이는 훨씬 더 좋아 보입니다.

• 제약 조건은 이해하기 어렵고 (대부분) 어셈블리 코드와 중복됩니다. 러스트에 명령의 충분히 상세한 모델이 있는 통합 어셈블러가 있다면 피연산자에 대한 제약 조건을 유추하여 오류와 혼란의 원인을 제거할 수 있습니다. 프로그래머가 명령어의 특정 인코딩을 필요로 하는 경우 명시적 제약 조건을 제공해야 하지만 일반적으로 이것은 필요하지 않습니다.

Norman Ramsey와 Mary Fernández는 어셈블리/기계어 쌍을 간결한 방식으로 설명하기 위한 훌륭한 아이디어가 있는 New Jersey Machine Code Toolkit 에 대한 몇 가지 논문을 저술했습니다. 그들은 (Pentium Pro-era) iA-32 명령어 인코딩을 다룹니다. 깔끔한 RISC ISA에 국한되지 않습니다.

가장 최근의 작업 주에서 얻은 결론을 다시 반복하고 싶습니다.

• 오늘날 우리가 아는 한 이 기능에 대한 문서는 기본적으로 없습니다. 여기에는 LLVM 내부 및 모든 것이 포함됩니다.
• 우리가 아는 한 LLVM은 안정성을 보장하지 않습니다. 우리는 LLVM의 인라인 어셈블리 구현이 언제든지 변경될 수 있다는 것을 알고 있습니다.
• 이것은 현재 Rustc에서 매우 버그가 많은 기능입니다. 컴파일 타임에 segfaults, ICE 및 이상한 LLVM 오류로 가득 차 있습니다.
• 사양이 없으면 이에 대한 대체 백엔드를 상상조차 하는 것이 거의 불가능합니다.

나에게 이것은 "지금 이것을 안정화하면 미래에 후회할 것을 보장할 것"의 정의이며 "유감스럽게도" 뿐만 아니라 "새로운 시스템을 구현하는 데 심각한 문제를 일으킬 가능성이 매우 높아 보입니다."

절대적으로 최소한의 총알(2)은 타협할 수 없다고 굳게 믿습니다(일명 "안정된 채널"에서 안정의 정의). 다른 총알은 현재 상당히 높은 Rust 컴파일러의 예상 품질을 저하시키기 때문에 포기하기에는 매우 슬플 것입니다.

@jcranmer 는 다음

LLVM은 특히 LLVM에 의해 생성되지 않은 명령어에서 어떤 레지스터가 클로버링되는지 실제로 식별하는 실제로 놀랍게도 나쁜 작업을 수행합니다. 이것은 사용자가 클로버링되는 레지스터를 수동으로 지정하는 것이 거의 필요하다는 것을 의미합니다.

실제로는 클로버 목록을 추론하는 것이 상당히 어려울 것이라고 생각합니다. 기계어 조각이 레지스터를 사용한다고 해서 레지스터를 방해하는 것은 아닙니다. 아마도 그것을 저장하고 복원합니다. 보수적인 접근 방식은 코드 생성기가 사용하기에 좋은 레지스터를 사용하지 못하게 할 수 있습니다.

@alexcrichton 은 다음

우리가 아는 한 LLVM은 안정성을 보장하지 않습니다. 우리는 LLVM의 인라인 어셈블리 구현이 언제든지 변경될 수 있다는 것을 알고 있습니다.

LLVM 문서는 "최신 릴리스는 이전 릴리스의 기능을 무시할 수 있지만 잘못 컴파일할 수는 없습니다."라고 보장합니다. (IR 호환성과 관련하여). 이는 인라인 어셈블리를 변경할 수 있는 범위를 제한하며, 위에서 논의한 것처럼 현재 상황에서 의미 체계를 근본적으로 변경하는 LLVM 수준에서 실제로 실행 가능한 대체품은 없습니다(예: Poison 및 undef에 대한 지속적인 문제와 달리). 따라서 잠재적인 불안정성으로 인해 Rust asm! 블록의 기반으로 사용할 수 없다고 말하는 것은 다소 부정직합니다. 이제 그것에 대해 다른 문제가 있다는 말은 아닙니다(개선되었지만 문서 상태가 좋지 않음, 불편함을 제약함, 진단이 좋지 않음, 덜 일반적인 시나리오의 버그가 마음에 떠오르는 것입니다).

스레드를 읽을 때 가장 큰 걱정은 우리가 완벽을 선의 적으로 만드는 것입니다. 특히 사람들이 asm 파서를 통합하고 LLVM과 함께 작동하도록 하면 더 많은 문제가 발생한다는 사실을 알게 됨에 따라 일부 마술 DSL 중개자를 찾는 데 인라인 asm에 사용할 수 있는 형식으로 씨름하는 데 몇 년이 걸릴 것이라고 걱정합니다. 엣지 케이스.

LLVM은 실제로 동작을 지정하지 않은 기능을 잘못 컴파일하지 않을 것이라고 보장합니까? 변경 사항이 잘못 컴파일되었는지 여부를 어떻게 결정할 수 있습니까? IR의 다른 부분에서도 볼 수 있었지만 이것은 많은 것을 기대하는 것 같습니다.

Clang에서도 그렇게 하지 않는데 LLVM의 형식으로 안정화하는 것이 이상할 것이라고 생각합니다.

Clang은 GCC용으로 작성된 코드를 컴파일하는 것을 목표로 하기 때문에 그렇게 하지 않습니다. Rustc는 그런 목적이 없습니다. GCC 형식은 인체공학적이지 않기 때문에 궁극적으로 우리는 그것을 원하지 않는다고 생각하지만, 지금으로서는 그것이 더 나은지 여부는 확실하지 않습니다. 현재 Rust 형식을 사용하는 많은 (야간) 코드가 있으며 GCC 스타일로 변경하면 중단될 수 있으므로 눈에 띄게 더 나은 것을 생각해낼 수 있는 경우에만 변경할 가치가 있습니다.

최소한 빌딩 블록은 잘 설계되어야 합니다. 제 생각에는 "expr" : foo : bar : baz 확실히 그렇지 않습니다.

동의. 최소한 저는 제약 조건과 클로버가 모두 하나의 목록에 있는 원시 LLVM 형식을 선호합니다. 현재 "=" 접두사를 지정하고 출력 목록에 넣어야 하는 중복성이 있습니다. 또한 LLVM이 출력이 표현식의 결과인 함수 호출처럼 처리하는 방법도 생각합니다. AFAIK 현재 asm! 구현은 "out" 매개변수가 있는 Rust의 유일한 부분입니다.

LLVM은 실제로 어떤 레지스터가 클로버링되는지 식별하는 실제로 매우 나쁜 작업을 수행합니다.

AFAIK LLVM은 인라인 어셈블리의 주된 이유가 LLVM이 이해하지 못하는 일부 코드를 포함하기 때문에 이 작업을 시도하지 않습니다. 실제 어셈블리를 보지 않고 레지스터 할당 및 템플릿 대체만 수행합니다. (물론 기계어를 생성하기 위해 어떤 단계에서 실제로 어셈블리를 파싱하지만 나중에 일어난다고 생각합니다)

외부 어셈블러를 생성하려는 경우

통합 인라인 어셈블러를 사용하는 것에 대한 대안이 있을 수 있는지 확신할 수 없습니다. LLVM이 레지스터를 할당하도록 하는 방법이 있기 때문입니다. 그러나 전역 어셈블리의 경우 외부 어셈블러를 사용할 수 있습니다.

LLVM 인라인 어셈블러의 주요 변경 사항과 관련하여 우리는 Clang과 같은 보트에 있습니다. 즉, 변경 사항이 있는 경우 변경 사항이 발생했을 때 해결해야 합니다.

clang이 지원하는 측면에서 정의된 것을 안정화하려면 clang_asm!이라고 불러야 합니다. 아셈! name은 다른 주요 Rust 기능과 마찬가지로 전체 RFC 프로세스를 통해 설계된 것으로 예약되어야 합니다. #자전거보관소

나는 그것을 위해 모든입니다. +1

현재 Rust 형식을 사용하는 많은 (야간) 코드가 있으며 GCC 스타일로 변경하면 중단될 수 있으므로 눈에 띄게 더 나은 것을 생각해낼 수 있는 경우에만 변경할 가치가 있습니다.

@parched 위에서 인용한 @jimblandy 의 제안에 따르면 asm! 사용하는 사람은 누구나 행복하게 계속 사용할 수 있습니다.

오늘날 우리가 아는 한 이 기능에 대한 문서는 기본적으로 없습니다. 여기에는 LLVM 내부 및 모든 것이 포함됩니다.

GCC의 어셈블리 구문이 30년 후에도 지정되거나 문서화되지 않은 경우, 문서화된 어셈블리 하위 언어를 생성하는 것이 너무 어려워서 우리의 제한된 리소스를 감안할 때 Rust의 능력을 넘어서는 작업이라고 가정하는 것이 안전해 보입니다. 어셈블리를 사용하려는 사람들은 단순히 신경 쓰지 않습니다.

우리가 아는 한 LLVM은 안정성을 보장하지 않습니다. 우리는 LLVM의 인라인 어셈블리 구현이 언제든지 변경될 수 있다는 것을 알고 있습니다.

GCC/Clang의 인라인 어셈블리 구현은 90년대 이후 작성된 모든 C 코드를 깨뜨릴 것이기 때문에 변경될 가능성은 거의 없습니다.

사양이 없으면 이에 대한 대체 백엔드를 상상조차 하는 것이 거의 불가능합니다.

냉담해질 위험을 무릅쓰고, 언어로서의 Rust가 어셈블리에 빠지는 당혹스러운 무능력으로 인해 살아남지 못한다면 대안적인 백엔드에 대한 전망은 무의미합니다. Nightly는 LLVM 변경의 전망보다 Rust의 안정성 보장을 약화시키는 Nightly 가 Rust라는 아이디어를 암묵적으로 지지하지 않는 한 Nightly로 충분하지 않습니다.

다른 총알은 현재 상당히 높은 Rust 컴파일러의 예상 품질을 저하시키기 때문에 포기하기에는 매우 슬플 것입니다.

내가 매일 Rust 개발자들의 태도와 그들이 유지하는 엄청난 품질 표준에 감사한다고 말하는 것은 거짓말이 아닙니다(사실 때때로 나는 여러분이 그 품질을 유지할 수 있도록 속도를 늦추기를 바랍니다 Brian처럼 자신을 태우지 않고). 그러나 luqmana가 4년 전에 asm! 매크로를 추가 했을 때 여기에 있었고 이후 안정화에 진전이 없었으며 Rust의 암호화가 여전히 불가능하고 SIMD가 Rust에서는 크로스 플랫폼 인터페이스가 천천히 결정되는 동안 해결 방법조차 없습니다. 저는 낙담합니다. 내가 여기에서 강조하는 것처럼 보이는 것은 이 문제를 프로젝트의 생존에 대한 실존적인 것으로 보기 때문입니다. 지금 당장은 위기가 아닐 수도 있지만, 모든 것을 안정화하는 데는 시간이 걸리고, 세계 수준의 어셈블리 언어를 처음부터 설계하고 구현하는 데 몇 년이 걸리지 않습니다. 우리는 지난 4년 동안 이에 대한 진전이 없었습니다.) Rust는 2018년 언젠가 안정적인 인라인 어셈블리 가 필요합니다. 이를 해내려면 선행 기술이 필요합니다. macro_rules! 상황은 때로는 더 나쁜 것이 더 낫다는 것을 인정했습니다. 다시 한번, 나는 누군가에게 내가 틀렸다는 것을 증명해달라고 간청합니다.

FWIW 및 파티에 늦게 오는 @florob 의 향수 토크가 제안한 것을 좋아합니다. 안 보신 분들을 위해 요지는 이렇습니다.

// Add 5 to variable:
let mut var = 0;
unsafe {
    asm!("add $5, {}", inout(reg) var);
}

// Get L1 cache size
let ebx: i32;
let ecx: i32;
unsafe {
    asm!(r"
        mov $$4, %eax;
        xor %ecx, %ecx;
        cpuid;
        mov %ebx, {};",
        out(reg) ebx, out(ecx) ecx, clobber(eax, ebx, edx)
    );
}
println!("L1 Cache: {}", ((ebx >> 22) + 1)
    * (((ebx >> 12) & 0x3ff) + 1)
    * ((ebx & 0xfff) + 1) * (ecx + 1));

다음 전략은 어떻습니까? 현재 asm 을 llvm_asm 변경하고(또한 약간의 약간의 변경이 있을 수 있음) 동작이 LLVM의 구현 세부 사항임을 명시하므로 Rust 안정성 보장이 완전히 확장되지 않습니까? 다른 백엔드의 문제는 사용되는 백엔드에 따라 조건부 컴파일 기능과 같은 target_feature 다소 해결되어야 합니다. 예, 이러한 접근 방식은 Rust 안정성을 약간 흐리게 만들지만, 이와 같이 어셈블리를 불안정한 상태로 유지하면 Rust 자체에 손상을 줍니다.

나는 내부 포럼( https://internals.rust-lang.org/t/pre-rfc-inline-assembly/6443)에 대체 구문 제안과 함께 사전 RFC를 게시했습니다. 피드백 환영합니다.

내가 보기에 최고는 확실히 여기에서 괜찮은 종류의 적입니다. 더 나은 솔루션이 개발되는 동안 현재로서는 gcc_asm! 또는 clang_asm! 또는 llvm_asm! 매크로(또는 적절한 하위 집합)를 호환 가능한 구문 및 의미 체계로 안정적으로 고정하는 것을 전적으로 지원합니다. . 큰 유지 관리 부담으로 그런 것을 영원히 지원하는 것은 아니라고 생각합니다. 위에서 제안한 보다 정교한 시스템은 구식 매크로를 새 매크로의 구문 사카린으로 바꾸는 것을 매우 쉽게 지원하는 것처럼 보입니다.

x86_64 popcntl 명령어에 대한 인라인 어셈블리가 필요한 바이너리 프로그램 http://[email protected]/BartMassey/popcount 가 있습니다. 이 인라인 어셈블리는 야간에 이 코드를 유지하는 유일한 것입니다. 코드는 12년 된 C 프로그램에서 파생되었습니다.

지금 내 어셈블리는

    #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]

그런 다음 popcnt 가 있는지 확인하기 위해 cpuid 정보를 가져옵니다. Rust의 최근 Google cpu_features 라이브러리 https://opensource.googleblog.com/2018/02/cpu-features-library.html 과 유사한 것을 Rust에 갖는 것이 좋겠지만 c'est la vie.

무엇보다 데모 프로그램이기 때문에 인라인 어셈블리를 유지하고 싶습니다. 실제 프로그램의 경우 count_ones() 내장으로 충분합니다. 단, popcntl 하려면 RUSTFLAGS 통해 Cargo에 "-C target-cpu=native"를 전달해야 합니다. (문제 #1137 및 여러 관련 문제 참조) 내 소스와 함께 .cargo/config 를 배포하는 것은 좋은 생각이 아닌 것 같습니다. 즉, 현재 Cargo를 호출하는 Makefile이 있다는 뜻입니다.

간단히 말해서 실제 응용 프로그램에서 Intel 및 타사의 멋진 popcount 명령을 사용할 수 있으면 좋겠지만 필요 이상으로 어려워 보입니다. 본질이 완전히 답은 아닙니다. 현재 asm! 는 안정적인 상태에서 사용할 수 있는 경우 괜찮은 답변입니다. 인라인 어셈블리를 위한 더 나은 구문과 의미 체계가 있으면 좋겠지만 실제로 필요하지는 않습니다. target-cpu=native 를 Cargo.toml 직접 지정할 수 있으면 좋겠지 target-cpu=native 실제로 문제가 해결되지는 않습니다.

죄송합니다. 내가 왜 이것에 관심이 있는지 공유할 생각입니다.

@BartMassey 이해가 안

@BartMassey 이를 위해 인라인 어셈블리를 사용할 필요조차 없습니다. coresimd cfg_feature_enabled!("popcnt") 를 사용하여 바이너리가 실행되는 CPU가 popcnt 명령을 지원하는지 쿼리하기

coresimd 는 popcnt 명령어 사용을 보장하는 popcnt 내장 함수도 제공합니다.

@gnzlbg

coresimd는 또한 popcnt 명령을 사용하도록 보장되는 popcnt 내장을 제공합니다.

약간 주제에서 벗어나지만 이 진술은 엄밀히 말하면 사실이 아닙니다. _popcnt64 는 내부적으로 leading_zeros 를 사용하므로 popcnt 기능이 crate 사용자에 의해 활성화되지 않고 crate 작성자가 #![cfg(target_feature = "popcnt")] 사용을 잊어버리면 이 내장 함수는 다음을 얻습니다. 비효율적인 어셈블리 로 컴파일되고 이에 대한 보호 장치 가

따라서 popcnt 기능이 crate 사용자에 의해 활성화되지 않는 경우

내장은 #[target_feature(enable = "popcnt")] 속성을 사용하여 crate 사용자가 활성화 또는 비활성화하는 것과 무관하게 내장에 대한 popcnt 기능을 무조건적으로 활성화하기 때문에 이것은 올바르지 않습니다. 또한 assert_instr(popcnt) 속성은 내장이 Rust가 지원하는 모든 x86 플랫폼에서 popcnt 로 분해되도록 합니다.

Rust가 현재 지원하지 않는 x86 플랫폼에서 Rust를 사용하는 경우, 이러한 내장 함수가 해당 대상에서 popcnt 를 생성하도록 core 를 이식하는 사람의 책임입니다.

편집: @newpavlov

따라서 popcnt 기능이 크레이트 사용자에 의해 활성화되지 않고 크레이트 작성자가 #![cfg(target_feature = "popcnt")] 사용을 잊어버리면 이 내장 함수는 비효율적인 어셈블리로 컴파일되고 이에 대한 보호 장치가 없습니다.

적어도 문제에서 언급한 예에서 이렇게 하면 프로그램에 정의되지 않은 동작이 도입되며 이 경우 컴파일러는 무엇이든 할 수 있습니다. 작동하는 나쁜 codegen은 얻을 수 있는 여러 결과 중 하나입니다.

먼저 토론에 차질이 생긴 점 사과드립니다. "저는 gcc_asm! 또는 clang_asm! 또는 llvm_asm! 매크로(또는 적절한 하위 집합)를 호환 가능한 구문 및 의미 체계로 안정적인 상태로 유지하는 것을 전적으로 지원합니다. 그 동안 더 나은 솔루션이 개발됩니다. "

인라인 어셈블리의 요점은 이것이 popcount 벤치마크/데모라는 것입니다. 가능한 경우 기준으로 그리고 인라인 어셈블리를 사용하는 방법을 설명하기 위해 진정한 보장된 popcntl 명령을 원합니다. 또한 가능한 경우 count_ones() 가 popcount 명령을 사용하여 Rustc가 GCC 및 Clang에 비해 끔찍해 보이지 않도록 보장하고 싶습니다.

target_feature=popcnt 지적해 주셔서 감사합니다. 여기에서 어떻게 사용할지 고민하겠습니다. 사용자가 컴파일하는 CPU와 popcount 명령이 있는지 여부에 관계없이 count_ones() 를 벤치마킹하고 싶습니다. 대상 CPU에 popcount count_ones() 가 있는지 확인하고 싶습니다.

stdsimd / coresimd 상자는 보기에 좋고 이 벤치마크에 대해 활성화해야 합니다. 감사 해요! 이 앱의 경우 표준 언어 기능 외에 가능한 한 적게 사용하는 것을 선호합니다(저는 이미 lazy_static 대해 죄책감을 느끼고 있습니다). 그러나 이러한 시설은 무시하기에는 너무 좋아 보이며 "공식"이 되기 위해 잘 가고 있는 것처럼 보입니다.

@nbp 에 의해

임의의 코드 바이트를 함수 내의 임의의 위치에 연결하는 것은 훨씬 더 쉽게 해결할 수 있는 문제처럼 보입니다.

cc @eddyb

@nagisa 단순한 기계어 코드가 아니라 입력, 출력 및 클로버 레지스터에 대해서도 주의해야 합니다. ASM 청크가 %rax의 특정 변수를 원하고 %esi를 방해한다고 말하면 주변 코드가 제대로 재생되는지 확인해야 합니다. 또한 개발자가 컴파일러가 레지스터를 할당하도록 허용하는 경우 값을 흘리거나 이동하는 것을 방지하기 위해 할당을 최적화하고 싶을 것입니다.

@simias , 실제로 변수가 특정 레지스터에 연결되는 방식과 어떤 레지스터가

바이트 시퀀스에 대한 표준화는 어셈블리 플레이버를 드라이버/프로시저 매크로로 이동하는 가장 쉬운 방법일 것입니다.

적절한 인라인 어셈블리 대신 축자 바이트를 사용하는 한 가지 문제는 컴파일러에 레지스터 알파 이름 바꾸기를 수행하는 옵션이 없다는 것입니다. 인라인 어셈블리를 작성하는 사람들도 기대하지 않습니다.

그러나 컴파일러가 이를 처리하도록 하려면 레지스터 할당과 함께 어떻게 작동할까요? 예를 들어, GCC의 (끔찍한) 구문을 사용하면 다음과 같습니다.

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

이와 같은 방식으로 컴파일러가 레지스터를 할당하도록 하여 가장 편리하고 효율적인 것을 제공할 것으로 기대합니다. 예를 들어 x86 64에서 five_time_x 가 반환 값이면 컴파일러는 eax 할당하고 x 가 함수 매개변수이면 일부 레지스터에서 이미 사용할 수 있습니다. 물론 컴파일러는 컴파일 시퀀스에서 꽤 늦게 레지스터를 할당하는 방법만 정확히 알고 있습니다(특히 단순히 함수 매개변수 및 반환 값만큼 사소하지 않은 경우).

제안한 솔루션이 이와 같은 방식으로 작동합니까?

@nbp 나는 이 제안에 약간 혼란스럽다고 말해야 한다.
우선, 어셈블리 언어를 표준화하는 것은 인라인 어셈블리로 달성하고자 하는 것이 결코 아니었습니다. 적어도 나에게 전제는 항상 시스템 어셈블러가 사용하는 어셈블리 언어가 받아들여질 것이라는 것이었습니다.
문제는 어셈블리를 구문 분석/어셈블하지 않는 것이므로 LLVM에 쉽게 전달할 수 있습니다.
문제는 템플릿 어셈블리를 채우고(또는 이를 수행하는 데 필요한 정보를 LLVM에 제공) 입력, 출력 및 클로버를 지정하는 것입니다.
나중의 문제는 실제로 귀하의 제안으로 해결되지 않습니다. 그러나 @simias 가 요청하는 레지스터 클래스를 지원하지 않거나 지원할 수 없기 때문에 완화되지만 구체적인 레지스터만 지원합니다.
제약 조건이 해당 확장으로 단순화되는 지점에서 실제로 "실제" 인라인 어셈블리를 지원하는 것만큼이나 쉽습니다. 첫 번째 인수는 (템플릿이 없는) 어셈블리를 포함하는 문자열이고 다른 인수는 제약 조건입니다. 이것은 LLVM의 인라인 어셈블러 표현식에 다소 쉽게 매핑됩니다.
반면에 원시 바이트를 삽입하는 것은 LLVM에서 지원하는 내가 아는 한(또는 LLVM IR 참조 설명서에서 알 수 있는 한) 아닙니다. 따라서 기본적으로 LLVM IR을 확장하고 별도의 상자를 사용하여 LLVM에 이미 있는 기능(시스템 어셈블리 조립)을 다시 구현합니다.

@nbp

실제로 변수가 특정 레지스터에 연결되는 방식과 어떤 레지스터가 클로버되는지를 지정해야 하지만 이 모든 것이 어셈블리 언어나 LLVM 어셈블리 언어를 표준화하는 것보다 작습니다.

어떻게 하면 될까요? 기본적으로 입력/출력 레지스터, 클로버 등이 모두 이 바이트 시퀀스 내에서 하드코딩된다는 것을 의미하는 하드코딩된 레지스터가 있는 바이트 시퀀스가 ​​있습니다.

이제 Rust 바이너리 어딘가에 이 바이트를 삽입합니다. 어떤 레지스터가 입력/출력인지, 어떤 레지스터가 클로버(clobbed)되었는지 등을 어떻게 Rustc에 알릴 수 있습니까? 인라인 어셈블리를 안정화하는 것보다 해결해야 할 더 작은 문제는 무엇입니까? 내가 보기에는 이것이 인라인 어셈블리가 하는 일입니다. 작성된 어셈블리에서 입력/출력 클로버를 두 번 지정해야 하고 어떤 방식으로든 이 정보를 rustc에 전달해야 하기 때문에 조금 더 어려울 수 있습니다. 또한, Rustc는 이를 검증하는 데 쉬운 시간이 없을 것입니다. 왜냐하면 이를 위해서는 바이트 시퀀스를 어셈블리로 구문 분석한 다음 이를 검사할 수 있어야 하기 때문입니다. 내가 무엇을 놓치고 있습니까?

@simias

asm ("leal (%1, %1, 4), %0"
     : "=r" (five_times_x)
     : "r" (x));

원시 바이트는 레지스터의 알파 이름 변경을 허용하지 않고 레지스터는 앞서 코드 시퀀스에 의해 시행되어야 하기 때문에 이것은 불가능합니다.

@플로롭

적어도 나에게 전제는 항상 시스템 어셈블러가 사용하는 어셈블리 언어가 받아들여질 것이라는 것이었습니다.

내 이해에 따르면 시스템 어셈블러에 의존하는 것은 우리가 의존하고 싶은 것이 아니라 asm의 일부로 허용되는 결함입니다! 매크로. 또한 asm에 의존! LLVM 구문이 되는 것은 추가 백엔드 개발에 고통스러울 것입니다.

@gnzlbg

어떻게 하면 될까요? 기본적으로 입력/출력 레지스터, 클로버 등이 모두 이 바이트 시퀀스 내에서 하드코딩된다는 것을 의미하는 하드코딩된 레지스터가 있는 바이트 시퀀스가 ​​있습니다.

아이디어는 입력, 출력 및 클로버된 레지스터 목록을 갖는 것입니다. 여기서 입력은 (변경 가능한) 참조 또는 복사와 관련된 레지스터 이름의 튜플이고 클로버된 레지스터는 레지스터 이름의 목록이 될 것입니다. 출력은 출력 레지스터의 목록이 될 것이며 관련 유형이 있는 명명된 레지스터의 튜플을 형성할 것입니다.

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_raw!{
       bytes: [0x91],
       inputs: [(std::asm::eax, a), (std::asm::ecx, b)],
       clobbered: [],
       outputs: (std::asm::eax, std::asm::ecx),
    }
  }
}

이 코드 시퀀스는 다음과 같은 일부 컴파일러 절차 매크로의 출력일 수 있습니다.

fn swap(a: u32, b: u32) -> (u32, u32) {
  unsafe{
    asm_x64!{
       ; <-- (eax, a), (ecx, b)
       xchg eax, ecx
       ; --> (eax, ecx)
    }
  }
}

이러한 시퀀스는 어떤 기호나 주소도 직접 포함할 수 없으며 계산되어 레지스터로 제공되어야 합니다. 나중에 바이트 시퀀스 내에 일부 기호 주소를 삽입하는 기능을 추가하는 방법을 알아낼 수 있을 것이라고 확신합니다.

이 접근 방식의 장점은 레지스터 및 제약 조건의 목록만 표준화하면 되며 이는 향후 모든 백엔드에서 쉽게 지원될 수 있다는 것입니다.

@nbp

내 이해에 따르면 시스템 어셈블러에 의존하는 것은 우리가 의존하고 싶은 것이 아니라 asm의 일부로 허용되는 결함입니다! 매크로. 또한 asm에 의존! LLVM 구문이 되는 것은 추가 백엔드 개발에 고통스러울 것입니다.

정확한 평가가 아닌 것 같은데요? x86 어셈블리에 대한 두 가지 다른 구문을 제외하고 어셈블리 구문은 대부분 표준이며 이식 가능합니다. 시스템 어셈블러의 유일한 문제는 최신 지침이 없다는 것일 수 있지만 최적화할 가치가 없는 틈새 상황입니다.

실제 문제는 레지스터 할당에 대한 접착제입니다. 그러나 실제 어셈블리 문자열 자체에 관한 한 이것은 누군가가 문자열 대체 작업과 일부 구문 분석을 수행해야 함을 의미하며 이러한 유형의 대체는 모든 추정 백엔드에서 쉽게 사용할 수 있어야 합니다.

이 항목에 대한 LLVM(또는 gcc)의 구문이 쓰레기라는 데 동의하지만 미리 컴파일된 바이트로 이동하면 모든 asm 크레이트가 이제 전체 어셈블러와 전체 레지스터 할당자를 설치해야 합니다(또는 프로그래머가 수동으로 레지스터를 할당하도록 함). 시스템 어셈블러를 사용합니다. 그 시점에서 실제로 많은 가치를 추가하는 것처럼 보이지 않습니다.

@jcranmer

... 하지만 미리 컴파일된 바이트로 이동한다는 것은 모든 asm 크레이트가 이제 전체 어셈블러와 아마도 전체 레지스터 할당자를 설치해야 하거나(또는 프로그래머가 레지스터를 수동으로 할당하도록) 시스템 어셈블러를 사용하려고 시도해야 한다는 것을 의미합니다.

https://github.com/CensoredUsername/dynasm-rs

이 크레이트는 플러그인이 처리하는 매크로를 사용하여 어셈블리 코드를 어셈블하고 런타임에 연결될 원시 어셈블리 코드의 벡터를 생성합니다.

@nbp 아마도 내 사용 사례는 독특하지만 레지스터 이름 변경이 부족하고 컴파일러가 레지스터를 할당하도록 하는 것은 내가 레지스터를 선택하는 데 매우 운이

어셈블리 blob이 주변 컴파일러 방출 어셈블리와 잘 통합되지 않으면 함수 호출에 동일한 유형의 레지스터가 있으므로 독립 실행형 .s 어셈블리 파일의 외부 C 스타일 메서드에서 ASM 스텁을 인수분해하는 것이 좋습니다. - 할당 제약. 이것은 이미 오늘날 작동하지만, Rustc에 빌드하면 독립 실행형 어셈블리 파일을 사용하는 것과 비교하여 빌드 시스템을 단순화할 수 있습니다. 내가 말하고자 하는 바는 IMO 귀하의 제안이 현재 상황에 비해 우리에게 그다지 도움이 되지 않는다는 것입니다.

그리고 ASM 코드가 링커에 의해 해결될 외부 기호를 호출하면 어떻게 될까요? 컴파일 프로세스가 끝날 때까지 해당 정보를 해결할 수 없기 때문에 해당 정보를 전달해야 합니다. 바이트 배열과 함께 참조를 전달하고 링커가 나중에 해결하도록 해야 합니다.

@jcranmer

x86 어셈블리에 대한 두 가지 다른 구문을 제외하고 어셈블리 구문은 대부분 표준이며 이식 가능합니다.

무슨 말인지 이해가 잘 안 갑니다. 분명히 ASM 구문은 아키텍처 간에 이식할 수 없습니다. 그리고 동일한 아키텍처 내에서도 언어가 조합되는 방식을 변경하는 변형과 옵션이 있는 경우가 많습니다.

MIPS를 예로 들 수 있습니다. 어셈블러 동작을 조정하는 두 가지 중요한 구성 플래그가 있습니다: at 및 reorder . at 는 어셈블러가 특정 의사 명령어를 어셈블할 때 AT (어셈블러 임시) 레지스터를 암시적으로 사용할 수 있는지 여부를 나타냅니다. 명시 적으로 사용하는 코드 AT 데이터를 저장하는 데 함께 조립해야합니다 at 또는 휴식 것입니다.

reorder 는 코더가 분기 지연 슬롯을 수동으로 처리하는지 또는 처리할 어셈블러를 신뢰하는지 정의합니다. 잘못된 reorder 설정으로 코드를 조합하면 거의 확실하게 가짜 기계 코드가 생성됩니다. MIPS 어셈블리를 작성할 때 분기 명령이 포함된 경우 항상 현재 모드를 알고 있어야 합니다. 예를 들어 reorder 가 활성화되어 있는지 모르는 경우 이 MIPS 목록의 의미를 알 수 없습니다.

    addui   $a0, 4
    jal     some_func
    addui   $a1, $s0, 3

32비트 ARM 어셈블리에는 Thumb/ARM 변형이 있으므로 대상으로 하는 명령어 세트를 아는 것이 중요합니다(함수 호출에서 즉석에서 변경할 수 있음). 두 세트를 혼합하는 것은 매우 신중하게 이루어져야 합니다. ARM 코드는 또한 일반적으로 암시적 PC 기준 로드를 사용하여 큰 즉시 값을 로드합니다. 코드를 미리 어셈블하는 경우 이러한 값이 가까이 있어야 하지만 실제 명령어가 아니기 때문에 이러한 값을 전달하는 방법에 대해 주의해야 합니다. 잘 정의 된 위치. 다음과 같은 의사 명령어에 대해 이야기하고 있습니다.

   ldr   r2, =0x89abcdef

반면 MIPS는 즉각적인 값을 두 개의 16비트 값으로 분할하고 lui/ori 또는 lui/andi 콤보를 사용하는 경향이 있습니다. 일반적으로 li / la 의사 명령어 뒤에 숨겨져 있지만 noreorder 코드를 작성하고 지연 슬롯을 낭비하고 싶지 않다면 때때로 처리해야 합니다. 그것을 손으로 하면 재미있는 코드가 나옵니다.

.set noreorder

   /* Display a message using printf */
   lui $a0, %hi(hello)
   jal printf
   ori $a0, %lo(hello)

.data

hello:
.string "Hello, world!\n"

%hi 및 %lo 구문은 각각 hello 기호의 상위 16비트 및 하위 16비트에 대한 참조를 생성하도록 어셈블리에 지시하는 방법입니다.

일부 코드에는 매우 독특한 정렬 제약 조건이 필요합니다. 그리고 앞에서 언급한 것처럼 컴파일 과정에서 이 시점에서 해결할 수 없는 외부 기호를 처리하는 문제가 있습니다.

나는 내가 잘 알지 못하는 다른 아키텍처들에 대한 특징을 생각해낼 수 있다고 확신합니다. 이러한 이유로 매크로/DSL 접근 방식에 대해 매우 낙관적이라고 확신할 수 없습니다. 코드 중간에 임의의 불투명한 문자열 리터럴을 갖는 것이 매우 우아하지 않다는 것을 이해하지만 전체 ASM 구문을 녹으로 통합하는 것이 어떤 식으로든 Rust에 대한 지원을 추가할 때 추가적인 골칫거리를 제외하고 우리에게 제공하는 것이 무엇인지 실제로 알지 못합니다. 새로운 아키텍처.

어셈블러를 작성하는 것은 언뜻 보면 사소해 보일 수 있지만 모든 아키텍처의 모든 종, 휘파람 및 단점을 지원하려는 경우 매우 까다로울 수 있습니다.

반면에 바인딩과 클로버를 지정하는 좋은 방법을 갖는 것은 매우 가치가 있을 것입니다(gcc의... 완벽한 구문과 비교하여).

안녕하세요 여러분,

귀찮게 해서 죄송합니다. 저는 2센트만 드리고 싶었습니다. 저는 사용자일 뿐이고 정말 수줍음이 많고 조용한 사람이기 때문입니다. 오, 그리고 새로 온 사람입니다. 저는 최근에 Rust에 도착했지만 이미 그것과 사랑에.

하지만 이 조립은 미친 짓입니다. 제 말은, 3년에 걸친 대화였습니다. 수많은 아이디어와 불평이 있었지만 최소한의 합의처럼 보이지는 않았습니다. RFC가 아닌 3년, 그것은 죽음의 끝과 같은 것 같습니다. 저는 겸손한 수학 라이브러리를 개발 중이며(두세 개의 상자에서 구체화되기를 바랍니다), 저에게(그리고 녹으로 어셈블리를 작성하는 데 관심이 있는 다른 사람에게) 가장 중요한 것은 실제로 다음을 수행할 수 있는 것입니다. 해! 다음 날 모든 것이 바뀌지 않을 것이라는 최소한의 보장과 함께(이것이 불안정한 채널, 특히 이 대화가 나를 느끼게 하는 이유입니다).

여기 있는 모든 사람들이 최상의 솔루션을 원하고 언젠가는 누군가가 그 솔루션을 내놓을 수도 있다는 것을 이해합니다. 하지만 오늘은 현재 매크로가 괜찮다고 믿습니다(음, 어떤 면에서 약간 제한적일 수 있지만 바라건대 그렇게 할 수 없는 것은 없습니다. 증분 방식으로 해결). 어셈블리를 작성하는 것은 시스템 언어에서 가장 중요한 것과 매우 필요한 기능입니다. 이 문제가 해결될 때까지 cpp_build에 의존하는 것은 괜찮지만 시간이 더 오래 걸리면 영원한 의존. 왜 그런지는 모르겠지만, 그것을 비합리적인 생각이라고 부르지만 어셈블리를 호출하기 위해 cpp를 호출해야 하는 것이 조금 슬프다는 것을 알게 되었습니다. 저는 순수한 녹 솔루션을 원합니다.

FWIW Rust는 여기에서 그렇게 특별하지 않습니다. MSVC에는 x86_64용 인라인 asm도 없습니다. 변수를 피연산자로 사용할 수 있지만 x86에서만 작동하는 정말 이상한 구현이 있습니다.

@josevalaad 인라인 어셈블리를 사용하는 말씀해 주 시겠습니까?

우리는 일반적으로 다른 이유로 야간에 멈춘 OS와 같은 상황에서만 사용되는 것을 보고 asm! 를 거의 사용하지 않으므로 asm! 안정화는 LLVM 외부에서 적절하게 생존할 수 있고 모두를 기쁘게 할 수 있는 것을 설계 및 개발하는 데 충분한 우선 순위가 있습니다.

또한 대부분의 작업은 노출된 플랫폼 내장 기능을 사용하여 수행할 수 있습니다. x86 및 x86_64 가 안정화되었으며 다른 플랫폼이 진행 중입니다. 대부분의 사람들은 이것이 목표의 95-99%를 달성할 것이라고 기대합니다. 일부 내장 기능을 사용하는 예로 내 자신의 크레이트 제트스키 를 볼 수 있습니다.

인라인 어셈블리를 사용하는 jemalloc PR을 병합하여 LLVM의 코드 생성 버그를 해결했습니다( https://github.com/jemalloc/jemalloc/pull/1303) . 이 문제(https://github.com/rust-lang/rust/issues/53232#issue-349262078)에서 누군가 jetscii 상자에서 발생한 Rust(LLVM)의 코드 생성 버그를 해결하기 위해 인라인 어셈블리를 사용했습니다. 둘 다 지난 2주 동안 발생했으며 두 경우 모두 사용자가 내장 함수를 시도했지만 컴파일러가 실패했습니다.

C 컴파일러에 대한 코드 생성이 허용되지 않는 경우 최악의 경우 사용자는 인라인 어셈블리를 사용하고 C에서 계속 작업할 수 있습니다.

이것이 안정적인 Rust에서 일어날 때, 지금 우리는 사람들에게 다른 프로그래밍 언어를 사용하거나 불확실한 시간(종종 몇 년 정도)을 기다리라고 말해야 합니다. 그것은 좋지 않다.

@eddyb 글쎄, 나는 작은 행렬 대수학 라이브러리를 작성 중입니다. 그 라이브러리 안에서 저는 BLAS를 구현하고 있습니다. 아마도 Rust의 일부 LAPACK(아직 없는) 루틴일 것입니다. 왜냐하면 라이브러리가 순수한 Rust 구현이기를 원했기 때문입니다. 아직 심각하지는 않지만 어쨌든 나는 사용자가 특히 GEMM 작업과 함께 필수적인 asm 속도와 재미를 선택할 수 있기를 원했습니다. 필요한 모든 것입니다), 최소한 x86/x86_64에서. 그리고 그것이 전체 이야기입니다. 분명히 야간 채널도 사용할 수 있습니다. 기능 안정화라는 실용적인 방향으로 조금 밀고 싶었습니다.

@shepmaster 내장 함수로는 충분하지 않은 사용 사례가 _

안정적인 인라인 asm은 중요하지만 내장 기능만으로는 충분하지 않습니다.

내 원래 요점은 누군가가 더 빠른 코드를 작성할 수 있도록 도우려는 것이었습니다. 그들은 내장 기능도 사용할 수 있다는 사실에 대해 언급하지 않았으며 이것이 제가 공유하려고 했던 전부입니다. 나머지는 배경 정보였습니다.

저는 특정 관점을 옹호하는 것도 아니므로 저와 논쟁하려고 하지 마십시오. 저는 이 경주에 아무런 이해관계가 없습니다. 나는 단지 현재의 관점이 내가 이해하는 바를 반복하고 있을 뿐입니다. 나는 가까운 장래에 내장이 없을 가능성이 매우 높은 인라인 어셈블리가 필요한 프로젝트에 참여하고 있기 때문에 어느 정도 안정적인 인라인 어셈블리에 관심이 있지만 야간 어셈블리는 나를 크게 괴롭히지 않으며 어셈블러를 호출하지도 않습니다.

예, 지금은 조립이 필요한 경우가 있고 영원히 필요할 경우가 있습니다. 원래대로 말했습니다(명확성을 위해 강조함).

대부분의 사람들은 [본질]이 목표의 95-99% 를 달성할 것이라고 기대합니다.

안정적인 어셈블리를 보고 싶다면 누군가(또는 사람들의 그룹)가 시작 방향에 대해 Rust 팀의 일반적인 합의를 얻은 다음 구현하기 위해 많은 노력을 기울여야 한다고 생각합니다. .

아직 심각하지는 않지만 어쨌든 나는 사용자가 특히 GEMM 작업과 함께 필수적인 asm 속도와 재미를 선택할 수 있기를 원했습니다. 필요한 모든 것입니다), 최소한 x86/x86_64에서.

인라인 어셈블리 없이는 액세스할 수 없는 액세스 지침이 무엇인지 여전히 이해하지 못합니다. 아니면 산술 명령어의 특정 시퀀스입니까?
그렇다면 인라인 어셈블리에 대해 동등한 Rust 소스를 벤치마킹했습니까?

인라인 어셈블리 없이는 액세스할 수 없는 액세스 지침

음, 수학에서 어셈블리에 대해 이야기할 때 기본적으로 _mm256_mul_pd, _mm256_permute2f128_pd 등과 같은 SIMD 레지스터 및 명령어 사용 및 진행되는 벡터화 작업에 대해 이야기하고 있습니다. 문제는 벡터화에 대해 다른 접근 방식을 취할 수 있다는 것입니다. 일반적으로 목표로 하는 프로세서와 염두에 두고 있는 용도에 대해 최적화된 성능을 얻을 때까지 약간의 시행착오를 거칩니다. 따라서 일반적으로 라이브러리 수준에서 지원되는 명령어 및 레지스터 집합을 알기 위해 asm 코드를 주입하는 프로세서에 먼저 쿼리한 다음 수학 asm 커널의 특정 버전을 조건부 컴파일해야 합니다.

그렇다면 인라인 어셈블리에 대해 동등한 Rust 소스를 벤치마킹했습니까?

지금 당장은 특별한 테스트가 없고 휴가 중이므로 많이 참여하지 않는 것이 좋습니다. 하지만 2주 정도 시간을 주시면 성능 비교를 게시할 수 있습니다. 어쨌든 컴파일러가 수동으로 조정된 어셈블리를 사용하여 가능한 한 빨리 코드를 생성하는 것은 불가능합니다. 필요한 경우 수동 루프 풀기 등과 같은 고전적인 성능 기술을 사용하더라도 최소한 C에서는 불가능하므로 Rust에서는 불가능해야 한다고 생각합니다.

Taylor Cramer가 여기에 게시할 것을 제안했습니다. 토론의 현재 상태를 파악하기 위해 모든 의견을 읽지 못한 점을 용서해 주십시오. 이것은 우리의 상황에 대한 지지와 성명일 뿐입니다.

Google의 베어메탈 프로젝트의 경우 인라인 및 모듈 수준 어셈블러 안정화에 대한 움직임을 보고 싶습니다. 대안은 FFI를 사용하여 순수 어셈블리로 작성되고 별도로 조립되고 바이너리로 함께 연결된 함수를 호출하는 것입니다.

우리 는 어셈블러에서 함수를 정의하고 FFI를 통해 호출하여 별도의 단계에서 연결할 수 있지만 복잡성과 성능 면에서 모두 단점이 있기 때문에 독점적으로 수행하는 심각한 베어메탈 프로젝트가 없다는 것을 알고 있습니다. Redox는 'asm!'을 사용합니다. Linux, BSD, macOS, Windows 등의 일반적인 용의자는 모두 인라인 어셈블러를 많이 사용합니다. 지르콘과 seL4가 그 역할을 합니다. 플랜 9조차도 몇 년 전 Harvey 포크에서 이에 대해 굴복했습니다.

성능이 중요한 항목의 경우 호출된 함수의 복잡성에 따라 함수 호출 오버헤드가 지배적일 수 있습니다. 복잡성 측면에서 볼 때, 단일 명령어를 호출하거나, 레지스터를 읽거나 쓰거나, 일반적으로 사용자 공간 프로그래머에게 숨겨져 있는 기계 상태를 조작하기 위해 별도의 어셈블러 기능을 정의하는 것은 더 지루한 상용구를 잘못 사용한다는 의미입니다. 어쨌든 우리는 이것을 하기 위해 Cargo를 사용할 때(또는 외부 빌드 시스템이나 쉘 스크립트 등으로 보완해야 할) 더 창의적이어야 합니다. 아마도 build.rs가 여기에서 도움이 될 수 있지만 링커에 공급하는 것이 더 어려워 보입니다.

또한 기호 상수의 값을 어셈블러 템플릿에 연결하는 방법이 있다면 매우 좋아할 것입니다.

인라인 및 모듈 수준 어셈블러 안정화에 대한 움직임을 보고 싶습니다.

마지막 pre-RFC(https://internals.rust-lang.org/t/pre-rfc-inline-assembly/6443)는 6개월 전에(적어도 대부분의 근본적인 문제에 대해) 합의를 얻었으므로 다음 단계는 그것을 기반으로 하는 RFC를 제출하는 것입니다. 이 작업을 더 빨리 수행하려면 @Florob 에 문의하는 것이 좋습니다.

그만한 가치가 있기 때문에 Windows에서 TEB 구조체에 대한 포인터를 얻으려면 FSGS 레지스터에 직접 액세스해야 합니다. 또한 bt 를 임의의 메모리 위치에 적용하려면 _bittest64 같은 내장 함수가 필요합니다. 인라인 어셈블리나 extern 호출 없이는 할 수 있는 방법을 찾지 못했습니다.

여기서 언급 된 세 번째 요점은 LLVM이 실제로 문제가 있는 경우 오류 메시지를 제공하지 않는 경우 Just Crash를 선호하기 때문에 저와 관련이 있습니다.

@MSxDOS

또한 bt를 임의의 메모리 위치에 적용하려면 _bittest64와 같은 내장 함수가 필요합니다. 둘 다 인라인 어셈블리나 extern 호출 없이 수행할 방법을 찾을 수 없습니다.

stdsimd 에 추가하는 것은 어렵지 않아야 합니다. clang은 인라인 어셈블리를 사용하여 이를 구현합니다(https://github.com/llvm-mirror/clang/blob/c1c07cca8cae5f924cedaac7b202b0f3c167111d/test/CodeGen/bittest-intrin .c#L45) 하지만 std 라이브러리에서 이를 사용하고 내장을 안전한 Rust에 노출할 수 있습니다.

누락된 내장 함수에 대해 stdsimd 리포지토리에서 문제를 여는 것이 좋습니다.

@josevalaad

음, 수학에서 어셈블리에 대해 이야기할 때 기본적으로 _mm256_mul_pd, _mm256_permute2f128_pd 등과 같은 SIMD 레지스터 및 명령어 사용 및 진행되는 벡터화 작업에 대해 이야기하고 있습니다.

아, 그럴지도 모른다는 생각이 들었다. 음, 시도해 보고 싶다면 어셈블리를 std::arch 내장 호출로 변환하고 동일한 성능을 얻을 수 있는지 확인할 수 있습니다.

그렇지 않은 경우 문제를 제출하십시오. LLVM은 마법이 아니지만 최소한 내장 기능은 asm만큼 좋아야 합니다.

@dancrossnyc 질문해도 됩니까? 귀하의 상황에서 특히 인라인 어셈블리가 필요한 사용 사례/플랫폼 기능이 있습니까?

@MSxDOS 어쩌면 "세그먼트" 레지스터를 읽기 위해 내장 함수를 노출해야 할까요?

아마도 우리는 데이터 수집을 하고 사람들 이 asm! 대해 정말로 원하는 것이 무엇인지 분석하고 그 중 얼마나 많은 것이 다른 방식으로 지원될 수 있는지 확인해야 합니다.

아마도 우리는 데이터 수집을 하고 사람들이 asm을 진정으로 원하는 것이 무엇인지 분석해야 할 것입니다!

다음을 위해 asm! 를 원합니다.

• 컴파일러에서 제공하지 않는 내장 함수 해결
• 컴파일러 버그 해결 / 차선의 코드 생성
• 단일 내장 호출 시퀀스를 통해 수행할 수 없는 작업 수행(예: 읽기 EFLAGS-modify-write EFLAGS 여기서 LLVM은 읽기와 쓰기 간에 eflag를 수정할 수 있으며 LLVM은 사용자가 수정하지 않을 것이라고 가정합니다. 이것은 뒤에 있습니다(즉, EFLAGS로 안전하게 작업하는 유일한 방법은 읽기-수정-쓰기 작업을 단일 원자 asm! 블록으로 작성하는 것입니다).

그리고 그 중 얼마나 많은 것이 다른 방식으로 지원될 수 있는지 확인하십시오.

어떤 형태의 인라인 어셈블리를 포함하지 않는 유스 케이스를 지원하는 다른 방법은 없지만 마음은 열려 있습니다.

RFC 이전 스레드의 내 게시물에서 복사한 다음은 현재 프로젝트에서 사용 중인 일부 인라인 어셈블리(ARM64)입니다.

// Common code for interruptible syscalls
macro_rules! asm_interruptible_syscall {
    () => {
        r#"
            # If a signal interrupts us between 0 and 1, the signal handler
            # will rewind the PC back to 0 so that the interrupt flag check is
            # atomic.
            0:
                ldrb ${0:w}, $2
                cbnz ${0:w}, 2f
            1:
               svc #0
            2:

            # Record the range of instructions which should be atomic.
            .section interrupt_restart_list, "aw"
            .quad 0b
            .quad 1b
            .previous
        "#
    };
}

// There are other versions of this function with different numbers of
// arguments, however they all share the same asm code above.
#[inline]
pub unsafe fn interruptible_syscall3(
    interrupt_flag: &AtomicBool,
    nr: usize,
    arg0: usize,
    arg1: usize,
    arg2: usize,
) -> Interruptible<usize> {
    let result;
    let interrupted: u64;
    asm!(
        asm_interruptible_syscall!()
        : "=&r" (interrupted)
          "={x0}" (result)
        : "*m" (interrupt_flag)
          "{x8}" (nr as u64)
          "{x0}" (arg0 as u64)
          "{x1}" (arg1 as u64)
          "{x2}" (arg2 as u64)
        : "x8", "memory"
        : "volatile"
    );
    if interrupted == 0 {
        Ok(result)
    } else {
        Err(Interrupted)
    }
}

@Amanieu 는 @japaric 이 ARM용 내장 기능을 위해 노력하고 있다는 점에 유의하십시오. 해당 제안이 귀하의 요구 사항을 충족하는지 확인할 가치가 있습니다.

@shepmaster

@Amanieu 는 @japaric 이 ARM용 내장 기능을 개발하고 있다는 점에 주목합니다. 해당 제안이 귀하의 요구 사항을 충족하는지 확인할 가치가 있습니다.

주목할 가치가 있습니다:

• 이 작업은 인라인 어셈블리를 대체하지 않고 단지 보완할 뿐입니다. 이 접근 방식은 std::arch 에서 공급업체 API를 구현합니다. 이러한 API는 이미 일부 사람들에게는 충분하지 않습니다.

• 이 접근 방식은 foo(); bar(); baz(); 와 같은 일련의 고유 호출이 해당 명령어 시퀀스와 구별할 수 없는 코드를 생성할 때만 사용할 수 있습니다. 반드시 그런 것은 아니며, 그렇지 않은 경우 올바른 것처럼 보이는 코드가 기껏해야 잘못된 결과를 생성합니다. 정의되지 않은 동작을 가지고 있으며, 최악의 결과는 (우리의이 때문에 버그를했다 x86 및 x86_64 에서 std 이미, 예를 들어, https://github.com/rust- lang-nursery/stdsimd/blob/master/coresimd/x86/cpuid.rs#L108 - 다른 아키텍처에도 이러한 문제가 있습니다.

• 일부 내장 함수에는 함수 호출을 통해 전달할 수 없는 즉시 모드 인수가 있으므로 foo(3) 가 작동하지 않습니다. 이 문제에 대한 모든 솔루션은 현재 엉뚱한 해결 방법이며 어떤 경우에는 현재 Rust에서 해결 방법이 불가능하므로 이러한 내장 기능 중 일부를 제공하지 않습니다.

따라서 공급업체 API가 Rust에서 구현 가능하고 std::arch 에서 사용 가능하고 문제를 해결하기 위해 결합될 수 있다면 인라인 어셈블리보다 낫다는 데 동의합니다. 그러나 때때로 API를 사용할 수 없거나 구현할 수 없거나 올바르게 결합할 수 없습니다. 향후 "구현성 문제"를 수정할 수 있지만 원하는 작업이 공급업체 API에 의해 노출되지 않거나 API를 결합할 수 없는 경우 이 접근 방식은 도움이 되지 않습니다.

LLVM의 내장 함수(특히 SIMD) 구현에 대해 매우 놀라운 점은 내장 함수를 명령에 대한 Intel의 명시적 매핑을 전혀 준수하지 않는다는 것입니다. 즉, 광범위한 컴파일러 최적화가 적용됩니다. 예를 들어 메모리에서 로드하는 대신 다른 상수에서 일부 상수를 계산하여 메모리 압력을 줄이려고 시도한 적이 있습니다. 그러나 LLVM은 내가 피하려고 했던 정확한 메모리 로드로 전체를 다시 일정하게 접기 시작했습니다. 다른 경우에는 port5 압력을 줄이기 위해 16비트 셔플을 8비트 셔플로 교체하는 방법을 조사하고 싶었습니다. 그러나 끝없는 지혜로 항상 도움이되는 LLVM 최적화 프로그램은 내 8비트 셔플이 실제로 16비트 셔플임을 알아차리고 이를 대체했습니다.

두 최적화 모두 확실히 더 나은 처리량(특히 하이퍼스레딩의 경우)을 제공하지만 내가 달성하기를 바랐던 대기 시간 감소는 아닙니다. 나는 결국 그 실험을 위해 nasm으로 떨어졌지만 내장 코드에서 일반 asm으로 코드를 다시 작성해야 하는 것은 불필요한 마찰이었습니다. 물론 나는 옵티마이저가 일부 고급 벡터 API를 사용할 때 명령어 선택이나 상수 폴딩과 같은 것들을 처리하기를 원합니다. 그러나 사용할 명령을 명시적으로 결정했을 때 컴파일러가 이를 어지럽히는 것을 정말로 원하지 않습니다. 유일한 대안은 인라인 asm입니다.

따라서 공급업체 API가 Rust에서 구현 가능하고 std::arch 에서 사용 가능하고 문제를 해결하기 위해 결합될 수 있다면 인라인 어셈블리보다 낫다는 데 동의합니다.

그게 내가 말을 봤는데 전부 처음

목표의 95-99% 달성

다시 한번

예, 지금은 조립이 필요한 경우가 있고 영원히 필요할 경우가 있습니다. 원래대로 말했습니다(명확성을 위해 강조함).

대부분의 사람들은 [본질]이 목표의 95-99%를 달성할 것이라고 기대합니다.

이것은 @eddyb 가 병렬로 말하는 것과 같습니다. 나는 현재 상황의 현실 을 지적하려고하면서 인라인 어셈블리의 유용성을 완전히 무시하는 것처럼 여러 사람들이 행동하는 이유가 확실하지 않습니다.

나는

1. 내장이 존재한다는 사실에 대해 언급하지 않은 한 포스터는 오늘날의 안정적인 내장을 향해 존재한다고 지적했습니다.
2. 제안에 대한 초기 피드백을 제공할 수 있도록 제안된 내장 요소에 대해 다른 포스터를 가리켰습니다.

이것을 매우 명확하게 말하겠습니다. 예, 인라인 어셈블리가 때때로 필요하고 좋습니다 . 나는 그것을 주장하지 않습니다. 저는 사람들이 현재 사용 가능한 도구를 사용하여 실제 문제를 해결하는 데 도움을 주려고 할 뿐입니다.

내가 말하려고 하는 것은 우리가 이에 대해 좀 더 조직적인 접근 방식, 적절한 설문조사를 해야 하고 이 스레드에서 우리 중 소수보다 훨씬 더 많은 데이터를 수집한 다음 이를 사용 하여 가장 일반적인 요구 사항을 지적

각 아키텍처에는 인라인 asm! 에서 약간의 사용을 얻는 까다로운 모델 하위 집합이 있다고 생각 하고 이러한 하위 집합에 초점을 맞춘 다음 일반화해야 할 수도 있습니다.

cc @rust-lang/lang

@eddyb _require_는 강력한 단어이며 인라인 어셈블러를 반드시 사용해야 하는 것은 아닙니다. 앞서 언급했듯이 순수 어셈블리 언어로 프로시저를 정의하고 별도로 어셈블한 다음 FFI를 통해 Rust 프로그램에 연결할 수 있습니다.

그러나 앞서 말했듯이 그렇게 하는 심각한 OS 수준 프로젝트는 없습니다. 이는 많은 보일러 플레이트(실수할 가능성이 더 높음), 더 복잡한 빌드 프로세스(지금 우리는 운이 좋게도 간단한 cargo 호출 및 연결된 거의 실행 준비가 된 커널이 반대쪽 끝에서 튀어나와 별도의 단계에서 어셈블러와 링크를 호출해야 하며 인라인 기능이 급격히 감소합니다. 거의 확실히 성능 저하가 있을 것입니다.

컴파일러 내장 함수와 같은 것은 많은 경우에 도움이 되지만 대상 ISA의 감독 명령어 세트, 특히 더 난해한 하드웨어 기능(예: 하이퍼바이저 및 엔클레이브 기능)의 경우 내장 함수가 없는 경우가 많습니다. no_std 환경. 내장된 기능으로는 충분하지 않은 경우가 많습니다. 예를 들어, x86-인터럽트 호출 규칙은 멋져 보이지만 트랩 프레임의 범용 레지스터에 대한 변경 가능한 액세스를 제공하지 않습니다. %rax 또는 무언가에서; 호출 규칙은 호출 사이트로 다시 전달하는 좋은 방법을 제공하지 않으므로 우리는 자체적으로 롤링해야 했습니다. 그것은 어셈블러에서 내 자신의 예외 처리 코드를 작성하는 것을 의미했습니다.

그래서 솔직히 말해서, 우리는 인라인 어셈블러를 _require_ 필요하지 않지만, 그것을 가지지 않는 것이 거의 초보자가 될 정도로 충분히 유용합니다.

@dancrossnyc 저는 특히 별도의 조립을 피하는 것 , 즉 링크하는 방법에 관계없이 프로젝트 에서 어떤 종류의 조립이 필요한지 궁금합니다.

귀하의 경우 수퍼바이저/하이퍼바이저/엔클레이브 권한 있는 ISA 하위 집합인 것 같습니다. 맞습니까?

종종 내장이 없습니다

이것은 필연적인 것입니까? 예를 들어 LLVM을 통해 내장 호출로 컴파일할 때 지침에 비합리적으로 어렵거나 유지하기조차 불가능한 요구 사항이 있습니까?
아니면 대부분의 개발자에게 유용하기에는 너무 특수한 경우라고 가정하기 때문입니까?

그리고 우리는 no_std 환경에 있습니다

기록을 위해 공급업체 내장 기능은 std::arch 및 core::arch (전자는 재수출).

x86 인터럽트 호출 규칙은 멋진 것처럼 보이지만 트랩 프레임의 범용 레지스터에 대한 변경 가능한 액세스를 제공하지 않습니다.

cc @rkruppe 이것이 LLVM에서 구현될 수 있습니까?

@eddyb 맞습니다. ISA의 감독자 하위 집합이 필요합니다. 현재로서는 특정 사용 사례에 대해 더 이상 말할 수 없습니다.

이것은 필연적인 것입니까? 예를 들어 LLVM을 통해 내장 호출로 컴파일할 때 지침에 비합리적으로 어렵거나 유지하기조차 불가능한 요구 사항이 있습니까?
아니면 대부분의 개발자에게 유용하기에는 너무 특수한 경우라고 가정하기 때문입니까?

어느 정도는 둘 다 사실이지만, 균형을 위해 나는 후자가 여기에서 더 적절하다고 말하고 싶습니다. 일부는 마이크로아키텍처에 따라 다르며 특정 프로세서 패키지 구성에 따라 다릅니다. 컴파일러가 (예를 들어) 특정 프로세서 버전에 따라 조건이 지정된 권한 있는 명령 하위 집합 _및_의 일부인 내장으로 무언가를 노출하는 것이 합리적입니까? 솔직히 모르겠다.

기록을 위해 공급업체 내장 함수는 std::arch와 core::arch 모두에 있습니다(전자는 다시 내보내기).

실제로 알아두면 좋습니다. 감사 해요!

컴파일러가 (예를 들어) 권한 있는 명령 하위 집합의 일부이고 특정 프로세서 버전을 조건으로 하는 내장으로 무언가를 노출하는 것이 합리적입니까? 솔직히 모르겠다.

우리는 이미 하고 있습니다. 예를 들어 xsave x86 명령어는 core::arch 에 구현 및 노출되며 모든 프로세서에서 사용할 수 없으며 대부분은 권한 모드가 필요합니다.

@gnzlbg xsave 은(는) 권한이 없습니다. xsaves 찾으셨습니까?

나는 https://rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/arch/x86_64/index.html을 살펴보고 내 빠른 청소에서 본 유일한 권한 있는 지침을 보았습니다(나는 전체 검색) xsaves , xsaves64 , xrstors 및 xrstors64 입니다. 나는 그것들이 일반 XSAVE* 계열에 속하고 리얼 모드에서 예외를 생성하지 않기 때문에 내장 함수라고 생각합니다. 일부 사람들은 clang/llvm을 사용하여 리얼 모드 코드를 컴파일하기를 원합니다.

@dancrossnyc 네, 그 중 일부는 제가 의미한 것입니다( xsave 모듈에서 xsave , xsaves , xsaveopt , ... 구현합니다: https: //github.com/rust-lang-nursery/stdsimd/blob/master/coresimd/x86/xsave.rs).

core 에서 사용할 수 있으므로 x86용 OS 커널을 작성하는 데 사용할 수 있습니다. 사용자 공간에서는 쓸모없는 AFAICT(항상 예외가 발생함)이지만 core 에서 이를 구분할 방법이 없습니다. 그러나 std 가 아니라 core 에만 노출될 수 있지만 이미 안정적이므로 해당 배는 항해했습니다. 누가 알겠습니까, 일부 OS는 언젠가 링 0에서 모든 것을 실행하고 거기서 사용할 수 있습니다...

@gnzlbg xsaveopt 또는 xsave 가 사용자 공간에서 예외를 발생시키는 이유를 모르겠습니다. xsaves 는 예외(#GP CPL>0인 경우), 그리고 보호 모드에서만(SDM vol.1 ch. 13; vol.2C ch. 5 XSAVES). xsave 및 xsaveopt 는 선점형 사용자 공간 스레드를 구현하는 데 유용하므로 내장 기능으로서의 존재가 실제로 의미가 있습니다. xsaves 에 대한 내장 기능은 누군가가 권한 문제를 깨닫지 않고 xsave 제품군의 모든 것을 추가했거나(즉, 사용자 공간에서 호출할 수 있다고 가정) 누군가가 그것을 호출하기를 원했기 때문이라고 생각합니다. 리얼 모드에서. 후자는 억지스러워 보일 수 있지만 사람들이 예를 들어 Clang 및 LLVM을 사용하여 리얼 모드 펌웨어를 구축하고 있다는 것을 알고 있습니다.

오해하지 마세요. core 에 LLVM 내장 함수가 있다는 것은 대단한 일입니다. rdtscp 의 결과를 유용한 형식으로 다시 가져오기 위해 어리석은 명령 시퀀스를 작성할 필요가 없다면 저는 기쁠 것입니다. 그러나 현재 내장 함수 세트는 커널이나 기타 베어 메탈 감독 종류를 작성할 때 인라인 어셈블러를 대체할 수 없습니다.

@dancrossnyc에서 xsave 를 언급할 때 CPUID 비트 XSAVE, XSAVEOPT, XSAVEC 등 뒤에서 사용할 수 있는 내장 기능 중 일부를 언급했습니다. 이러한 내장 기능 중 일부는 특권 모드가 필요합니다.

컴파일러가 (예를 들어) 권한 있는 명령 하위 집합의 일부이고 특정 프로세서 버전을 조건으로 하는 내장으로 무언가를 노출하는 것이 합리적입니까?

우리는 이미 그렇게 하고 있으며 안정적인 Rust에서 사용할 수 있습니다.

xsave의 고유 기능은 누군가가 권한 문제를 깨닫지 않고 xsave 제품군의 모든 것을 방금 추가했기 때문이라고 생각합니다.

이러한 내장 기능을 추가했습니다. 우리는 권한 문제를 깨달았고 core 에 의존하는 프로그램이 이것을 사용하려는 OS 커널이 되는 것이 완벽하고 사용자 공간에서 무해하기 때문에 어쨌든 추가하기로 결정했습니다

그러나 현재 내장 함수 세트는 커널이나 기타 베어 메탈 감독 종류를 작성할 때 인라인 어셈블러를 대체할 수 없습니다.

동의합니다. 그렇기 때문에 이 문제가 아직 열려 있습니다. ;)

@gnzlbg 죄송합니다. xsave et al.

그러나 내가 말할 수 있는 한 권한 있는 실행이 필요한 유일한 내장 함수는 xsaves 와 관련된 내장 함수이고 항상 권한이 있는 것은 xsaves 및 xrstors 는 권한 있는 명령어 세트의 아주 작은 부분이며 두 명령어에 대해 내장 함수를 추가하는 것은 일반적으로 그렇게 하는 것과 질적으로 다르며 다음과 같은 질문이 남아 있다고 생각합니다. _일반적으로_ 적절합니다. 예를 들어 VMX 확장의 VMWRITE 명령을 고려하십시오. 내장 함수가 명령 실행과 같은 작업을 수행한 다음 rflags "반환"한다고 상상합니다. 그것은 본질적으로 가지고 있는 일종의 이상하게 전문화된 것입니다.

그렇지 않으면 우리는 여기에 동의한다고 생각합니다.

std::arch RFC에 따라 FWIW는 현재 공급업체가 API에서 노출하는 std::arch 에만 내장 함수를 추가할 수 있습니다. xsave 경우 Intel은 C API에 이를 노출 하므로 거기에 있는 것이 좋습니다. 현재 노출되지 않은 공급업체 내장 기능이 필요한 경우 권한 모드가 필요한지 여부와 관계없이 문제를 엽니다.

공급업체가 내장 기능을 노출하지 않으면 std::arch 가 적합하지 않을 수 있지만 이에 대한 많은 대안이 있습니다(인라인 어셈블리, 글로벌 asm, C 호출 등).

죄송합니다. xsave 에 대한 내장 기능을 Intel 내장 기능을 의미하기 위해 작성했다고 말씀하신 것을 이해했습니다. 내가 xsaves 가 내재적이라고 생각하는 이유에 대한 내 이전 의견은 여전히 ​​적용됩니다(Intel의 컴파일러 작성자의 사고이거나 누군가가 리얼 모드를 원했기 때문입니다. 전자는 정말 빨리 알아차릴 수 있을 것 같지만 펌웨어는 이상한 일을 하므로 후자는 전혀 놀라지 않을 것입니다).

어쨌든, 네, 저는 우리가 근본적으로 동의한다고 생각합니다. 내장 함수는 모든 것을 위한 장소가 아니며, 이것이 우리가 asm!()이 안정으로 옮겨진 것을 보고 싶은 이유입니다. 어제 말씀하신 것처럼 이 영역에서 진전이 이루어지고 있다는 소식을 들으니 정말 기쁩니다. @Florob 이 이것을 스택의 맨 위에 더 가깝게 버블

asm! 대한 몇 가지 추가 세부정보 및 사용 사례:

운영 체제, 펌웨어, 특정 유형의 라이브러리 또는 기타 특정 유형의 시스템 코드를 작성할 때 플랫폼 수준 어셈블리에 대한 전체 액세스 권한이 필요합니다. Rust가 지원하는 모든 아키텍처에서 모든 단일 명령어를 노출하는 내장 함수가 있더라도(이는 거의 갖고 있지 않음) 사람들이 인라인 어셈블리로 정기적으로 끌어오는 일부 스턴트에는 여전히 충분하지 않습니다.

다음은 다른 방법으로는 쉽게 수행할 수 없는 인라인 어셈블리로 수행할 수 있는 작업의 작은 부분입니다. 이들 각각은 내가 본(또는 어떤 경우에는 작성된) 실제 사례이며 가상이 아닙니다.

• 별도의 ELF 섹션에 특정 패턴의 명령어 구현을 모두 수집한 다음 코드를 로드할 때 실행 중인 시스템의 특성에 따라 런타임에 해당 섹션을 패치합니다.
• 대상이 런타임에 패치되는 점프 명령어를 작성합니다.
• 중간에 잠재적인 중단을 신중하게 처리하는 패턴을 구현할 수 있도록 정확한 명령어 시퀀스 를 내보내십시오(개별 명령어에 대해 내장 함수를 사용할 수 없음).
• 명령을 내보낸 다음 asm 블록의 끝으로 점프한 다음 명령이 오류를 생성하는 경우 하드웨어 오류 처리기가 점프할 오류 복구 코드가 뒤따릅니다.
• 어셈블러가 아직 알지 못하는 명령어에 해당하는 바이트 시퀀스를 내보냅니다.
• 신중하게 다른 스택으로 전환한 다음 다른 함수를 호출하는 코드를 작성하십시오.
• 특정 레지스터의 인수가 필요한 어셈블리 루틴 또는 시스템 호출을 호출합니다.

+1e6

@eddyb

좋아, 나는 내장 접근법을 시도하고 그것이 필요한 곳을 볼 것이다. 당신이 옳을 것이고 그것이 제 경우에 가장 좋은 접근 방식입니다. 감사합니다!

@joshtriplett 가 성공했습니다! 이것들은 내가 염두에 둔 정확한 사용 사례입니다.

loop {
   :thumbs_up:
}

몇 가지 다른 사용 사례를 추가하겠습니다.

• BIOS/EFI 호출 및 16비트 리얼 모드와 같은 이상한 아키텍처 모드에서 코드를 작성합니다.
• 이상하거나 특이한 주소 지정 모드로 코드 작성(16비트 리얼 모드, 부트로더 등에서 자주 나타남)

@mark-im 물론입니다! 그리고 두 목록 모두에 하위 사례가 있는 요점을 일반화합니다. 호출 규칙 간에 변환합니다.

저는 이 문제에 찬성하여 #53118을 마감하고 기록을 위해 여기에 PR을 복사합니다. 이것은 8월의 것이지만 간단히 살펴보면 상황이 변경되지 않았음을 나타냅니다.

인라인 어셈블리 섹션 은 정밀 검사가 필요합니다. 현재 상태에서는 동작과 구문이 rustc 및 일반적으로 Rust 언어에 묶여 있음을 의미합니다. 거의 전체 문서는 llvm 도구 체인을 사용하는 x86/x86_64 어셈블리에만 해당됩니다. 분명히 말해서, 나는 분명히 플랫폼에 특정한 어셈블리 코드 자체를 말하는 것이 아니라 인라인 어셈블리의 일반적인 아키텍처와 사용법을 말하는 것입니다.

ARM 타겟과 관련하여 인라인 어셈블리 동작에 대한 신뢰할 수 있는 소스를 찾지 못했지만 내 실험 및 ARM GCC 인라인 어셈블리 설명서 참조 에 따르면 다음 사항이 완전히 잘못된 것 같습니다.

• ARM/MIPS(및 대부분의 다른 CISC?)와 같은 ASM 구문은 대상 레지스터와 함께 Intel-esque 구문을 먼저 사용합니다. 인라인 asm이 실제 플랫폼/컴파일러별 구문으로 변환된 at&t 구문을 사용했으며 x86 레지스터 이름을 ARM 레지스터 이름으로만 대체해야 함을 의미/암시하는 문서를 이해했습니다.
• 이와 관련하여 intel 옵션은 유효하지 않으며 컴파일할 때 "알 수 없는 지시문" 오류가
• ARM GCC 인라인 어셈블리 문서 ( arm-none-eabi-* 도구 체인을 사용하여 thumbv7em-none-eabi 에 대해 빌드하는 경우 인라인 어셈블리 형식에 대한 몇 가지 기본 가정조차도 플랫폼에 따라 다릅니다. ARM의 경우 출력 레지스터(두 번째 매크로 인수)는 레지스터 참조로 계산됩니다. 즉, $0 는 x86 llvm 명령어의 경우와 같이 첫 번째 입력 레지스터가 아니라 첫 번째 출력 레지스터를 참조합니다.
• 동시에 다른 컴파일러 관련 기능은 _not_ 존재하지 않습니다. 레지스터에 명명된 참조를 사용할 수 없으며 인덱스만 사용할 수 있습니다(예: asm("mov %[result],%[value],ror #1":[result] "=r" (y):[value] "r" (x)); 는 유효하지 않음).
• (x86/x86_64 타겟의 경우에도 인라인 어셈블리 예제에서 $0 및 $2 의 사용법은 해당 숫자가 선택된 이유를 설명하지 않기 때문에 매우 혼란스럽습니다.)

저에게 가장 충격을 줬던 것은 다음과 같은 마지막 문장이라고 생각합니다.

현재 asm 구현! 매크로는 LLVM의 인라인 어셈블러 표현식에 대한 직접 바인딩이므로 클로버, 제약 조건 등에 대한 자세한 내용은 설명서도 확인하십시오.

보편적으로 사실이 아닌 것 같습니다.

인라인 asm이 실제 플랫폼/컴파일러별 구문으로 변환된 at&t 구문을 사용했으며 x86 레지스터 이름을 ARM 레지스터 이름으로만 대체해야 함을 의미/암시하는 문서를 이해했습니다.

intel 대 at&t 구문의 개념은 x86에만 존재합니다(내가 알지 못하는 다른 경우가 있을 수 있음). 동일한 이진 코드 세트를 나타내기 위해 동일한 니모닉 세트를 공유하는 두 개의 다른 언어라는 점에서 독특합니다. GNU 생태계는 at&t 구문을 x86 세계의 지배적인 기본값으로 설정했습니다. 이것이 인라인 asm이 기본값으로 사용되는 이유입니다. 이것이 LLVM의 인라인 어셈블러 표현식에 대한 직접적인 바인딩이라는 점에서 착각하고 있습니다. 이 표현식은 대부분 일반 텍스트(대체 처리 후)를 텍스트 어셈블리 프로그램에 덤프합니다. 이 중 어느 것도 오늘날의 asm!() 고유하거나 관련이 없습니다. 이는 전적으로 플랫폼에 따라 다르며 x86 세계를 넘어서는 완전히 무의미하기 때문입니다.

이와 관련하여 intel 옵션은 유효하지 않으며 컴파일할 때 "알 수 없는 지시문" 오류가 발생합니다.

이것은 위에서 설명한 "멍청한"/단순한 일반 텍스트 삽입의 직접적인 결과입니다. 오류 메시지는 .intel_syntax 지시문이 지원되지 않음을 나타냅니다. 이것은 intel 스타일 inline-asm을 GCC(att 스타일을 내보냄)와 함께 사용하기 위한 오래되고 잘 알려진 해결 방법입니다. 인라인 asm 블록의 시작 부분에 .intel_syntax 를 쓴 다음 일부 intel-asm을 작성하면 됩니다. asm 스타일을 지정하고 마지막으로 .att_syntax 로 종료하여 어셈블러를 att 모드로 다시 설정하여 (다음) 컴파일러 생성 코드를 다시 한 번 올바르게 처리합니다. 그것은 더러운 해킹이며 적어도 LLVM 구현이 오랫동안 이상한 단점을 가지고 있었기 때문에 마침내 제거되었기 때문에 이 오류가 표시되는 것처럼 보입니다. 슬프게도, 여기서 유일한 올바른 조치는 Rustc에서 "intel" 옵션을 제거하는 것입니다.

인라인 어셈블리 형식에 대한 몇 가지 기본 가정조차도 플랫폼에 따라 다릅니다.

귀하의 관찰은 완전히 정확합니다. 각 플랫폼은 자체 바이너리 형식과 자체 어셈블리 언어를 모두 구성합니다. 그것들은 완전히 독립적이며 (대부분) 컴파일러에 의해 처리되지 않습니다. 이것이 원시 어셈블러 프로그래밍의 요점입니다!

레지스터에 명명된 참조를 사용할 수 없으며 인덱스만 사용할 수 있습니다.

슬프게도 Rustc가 노출하는 LLVM의 인라인 asm 구현과 (clang이 에뮬레이트하는) GCC 구현 사이에는 상당한 불일치가 있습니다. asm!() 로 앞으로 나아갈 방법에 대한 결정이 없으면 이를 개선할 동기가 거의 없습니다. 게다가 저는 오래전에 주요 옵션에 asm!() 에 갇혀 있을 것입니다. 적절한 해결 방법이 있습니다.

• 최적화 프로그램에 의존하여 최적의 코드 생성
• 거의 모든 면에서 인라인 asm보다 더 나은 또 다른 매우 우아한 솔루션인 내장 기능을 사용하십시오(명령 선택 및 일정을 정확하게 제어해야 하는 경우 제외).
• 인보 cc 에서 상자 build.rs 인라인 ASM으로 C 객체를 연결하는
  
  
  
  • 기본적으로 build.rs 에서 원하는 어셈블러를 호출하기만 하면 C 컴파일러를 사용하는 것이 과도하게 보일 수 있지만 build.rs 시스템과 통합하는 번거로움을 덜어줍니다.
  
  

이러한 해결 방법은 매우 특정한 극단적인 경우를 제외하고는 모두 적용됩니다. 당신이 그 중 하나를 치면 (다행히 나는 아직 하지 않았다) 당신은 운이 없습니다.

나는 문서가 상당히 부족하다는 데 동의하지만 인라인 asm에 익숙한 사람에게는 충분합니다. 그렇지 않은 경우 사용하지 않아야 합니다 . 오해하지 마세요. 자유롭게 실험하고 배울 수 있어야 하지만 asm!() 는 불안정하고 무시되며 정말 좋은 해결 방법이 있기 때문에 가능하면 진지한 프로젝트에서 사용하지 말라고 강력히 조언합니다. .

C 개체를 인라인 asm과 연결하기 위해 build.rs에서 cc 상자를 호출합니다.

또한 build.rs 에서 cc 크레이트를 호출하여 최대 제어 수준을 제공하는 일반 어셈블리 파일을 빌드할 수 있습니다. 위의 두 가지 "해결 방법"이 사용 사례에서 작동하지 않는 경우를 대비하여 정확히 이 작업을 수행하는 것이 좋습니다.

@main-- 쓴:

이러한 해결 방법은 매우 특정한 극단적인 경우를 제외하고는 모두 적용됩니다. 당신이 그 중 하나를 치면 (다행히 나는 아직 하지 않았다) 당신은 운이 없습니다.

완전히 운이 좋지는 않습니다. Rust의 inline asm 됩니다. 여기에 나열된 해결 방법 중 어느 것도 다루지 않는 극단적인 경우가

(저에게는 또 다른 사용 사례가 있습니다. 저는 언젠가 C 대신 Rust를 사용하여 컴퓨터 아키텍처와 물건을 프로그래밍하는 시스템을 가르치고 싶습니다. 인라인 어셈블리가 없으면 훨씬 더 어색합니다.)

우리가 Rust에서 인라인 어셈블리를 우선순위로 삼고 빨리 안정화되기를 바랍니다. 이것은 Rust 2019의 목표일 것입니다. 나는 이전에 좋은 의견에 나열한 솔루션 중 어느 것이든 괜찮습니다. 어셈블리 코드를 인라인할 수 있다는 것은 어디에서나 C 대신 Rust를 작성하기 위한 전제 조건입니다. 안정적이려면 정말 필요합니다.

우리가 Rust에서 인라인 어셈블리를 우선순위로 삼고 빨리 안정화되기를 바랍니다. 이것은 Rust 2019의 목표일 것입니다.

Rust 2019 블로그 게시물을 작성하고 이 우려를 표현하세요. 우리 중 충분히 그렇게 한다면 로드맵에 영향을 미칠 수 있다고 생각합니다.

위의 내 의견을 명확히 하기 위해 - 문제는 문서가 asm!(..) 매크로의 내용이 구문 분석/상호작용하는 방법을 "깊이" 설명하지 않는다는 것입니다. 저는 x86 및 MIPS/ARM 어셈블리에 익숙하지만 llvm에는 자체 어셈블리 언어 형식이 있다고 가정합니다. 이전에 x86용 인라인 어셈블리를 사용한 적이 있지만 C와 ASM을 연결하기 위한 asm의 나쁜 짓이 어느 정도 진행되었는지 명확하지 않았습니다. 러스트 인라인 어셈블리 섹션의 문구를 기반으로 한 내 추정(현재 무효화됨)은 LLVM이 at&t 또는 intel 모드에서 x86 어셈블리를 모방하도록 구축된 자체 ASM 형식을 가지고 있으며 반드시 표시된 x86 예제와 유사해야 한다는 것입니다.

(나를 도운 것은 확장된 매크로 출력을 연구하는 것이었고, 이는 진행 중인 일을 정리했습니다.)

나는 그 페이지에서 덜 추상화될 필요가 있다고 생각한다. LLVM에 의해 구문 분석되는 항목과 ASM으로 직접 해석되는 항목을 더 명확하게 합니다. 어떤 부분이 녹과 관련이 있는지, 어떤 부분이 실행 중인 하드웨어에 특정한지, 그리고 어떤 부분이 이들을 함께 고정시키는 접착제에 속하는지 등입니다.

인보 cc 행 상자 build.rs 인라인 ASM와 C의 오브젝트를 연결하는

교차 언어 LTO 에 대한 최근의 발전으로 인해 이 방법의 일부 단점이 줄어들어 이 "외부 어셈블리 blob"을 효과적으로 인라인할 수 있는지 궁금합니다. ( 아마도 )

인보 cc 행 상자 build.rs 인라인 ASM와 C의 오브젝트를 연결하는

교차 언어 LTO 에 대한 최근의 발전으로 인해 이 방법의 일부 단점이 줄어들어 이 "외부 어셈블리 blob"을 효과적으로 인라인할 수 있는지 궁금합니다.

이것이 작동하더라도 C로 인라인 어셈블리를 작성하고 싶지 않습니다. Rust로 작성하고 싶습니다. :-)

인라인 어셈블리를 C로 작성하고 싶지 않습니다.

.s 및 .S 파일을 직접 컴파일하고 연결할 수 있습니다(예: 이 crate 참조). 내 책에서는 C에서 충분히 멀리 떨어져 있습니다. :)

이 도로의 단점 중 일부를 줄일 수 있다면

언어 간 LTO가 LLVM IR에 의존하고 어셈블리가 이것을 생성하지 않기 때문에 이것이 현재 실현 가능하지 않다고 생각합니다.

언어 간 LTO가 LLVM IR에 의존하고 어셈블리가 이것을 생성하지 않기 때문에 이것이 현재 실현 가능하지 않다고 생각합니다.

LLVM IR 모듈의 모듈 수준 어셈블리에 어셈블리를 채울 수 있습니다.

가장 최근의 제안/현재 상태가 무엇인지 아는 사람이 있습니까? 올해의 주제는 "성숙과 우리가 시작한 일의 마무리"이기 때문에 마침내 asm 마무리할 수 있는 좋은 기회인 것 같습니다.

새로운 (안정화될) 구문에 대한 막연한 계획은 지난 2월에 논의되었습니다: https://paper.dropbox.com/doc/FFI-5NmXV30TGiSsr9dIxpqpq

그 메모에 따르면 @joshtriplett 와 @Amanieu 는 RFC를 작성하기 위해 서명했습니다.

새 구문의 상태는 무엇입니까?

RFC를 적용하고 야간에 구현해야 합니다.

ping @joshtriplett @Amanieu 여기로 이동하는 것을 도울 수 있는지 알려주세요! 곧 연락드리겠습니다.

@cramertj AFAICT 누구나 이 작업을 개입 하여 작업을 수행하기를 기다리고 있습니다. 전체 디자인을 스케치하는 사전 RFC가 있으며 다음 단계는 이를 구현하고 proc 매크로, 포크 또는 다른 불안정한 기능으로 실제로 작동하는지 확인하는 것입니다.

아마도 pre-RFC를 적절한 RFC로 변환하여 제출하려고 할 수 있지만 구현 없이 그러한 RFC가 설득력이 있을 수 있는지 의심스럽습니다.

편집: 분명히 하기 위해 나는 다음과 같은 pre-RFC의 일부를 의미한다고 확신합니다.

추가로 레지스터 클래스에 대한 매핑이 적절하게 추가됩니다(cf. llvm-constraint 6).

lang-ref에는 수십 개의 아치별 레지스터 클래스가 있습니다. RFC는 이 모든 것을 그냥 넘길 수 없으며, 모든 것이 예상대로 작동하거나 의미가 있거나 여기에서 노출될 LLVM에서 충분히 "안정적"인지 확인하는 등의 구현에서 이점을 얻을 수 있습니다. 그냥 이것들을 시도하십시오.

여기서 #![feature(asm)] RISC-V 인라인 어셈블리가 지원됩니까?

내가 아는 한, 지원되는 플랫폼의 모든 어셈블리가 지원됩니다. llvm 컴파일러의 asm 지원에 대한 거의 원시 액세스입니다.

예, RISC-V가 지원됩니다. 아키텍처별 입력/출력/ 클로버 제약 클래스는

그러나 주의 사항이 있습니다. 입력/출력/클로버 제약 조건에서 개별 레지스터를 제한해야 하는 경우 ABI 이름이 아닌 아키텍처 레지스터 이름(x0-x31, f0-f31)을 사용해야 합니다. 어셈블리 조각 자체에서 두 종류의 레지스터 이름 중 하나를 사용할 수 있습니다.

이러한 개념을 처음 접하는 사람으로서 제가 말할 수 있는 것은... 이 전체 토론은 _어리석은_ 것 같습니다. 기계 코드와 1:1 매핑 이 되어야 하는 언어(어셈블리)가 어떻게 이토록 골치 아픈 일을 일으키나요?

나는 꽤 혼란 스럽다 :

• 당신은 ASM을 작성하는 경우, 그것은 (와 인간에 의해 다시 쓸 필요가 없습니다 #[cfg(...)] 모든 아키텍처) _and 당신이 지원하려고하는 backend_?
• 이것은 "구문" 질문이 무의미하다는 것을 의미합니다... 해당 아키텍처에 대한 구문을 사용하고 컴파일러가 사용하게 되는 백엔드를 사용하십시오.
• Rust는 바이트를 올바른 레지스터에 넣고 어떤 아키텍처에 대해 컴파일되는지에 대해 스택에 푸시/팝을 할 수 있는 std 안전하지 않은 함수가 필요합니다. 다시 말하지만 이것은 모든 아키텍처와 심지어 모든 백엔드에 대해 다시 작성해야 할 수도 있습니다.

이전 버전과의 호환성이 문제라는 것은 알지만 엄청난 수의 버그와 이것이 결코 안정화되지 않았다는 사실로 인해 백엔드로 전달하는 것이 더 나을 수도 있습니다. Rust는 LLVM이나 gcc 또는 다른 사람의 잘못된 구문을 수정하려고 해서는 안 됩니다. Rust는 목표로 삼고 있는 아키텍처와 컴파일러를 위한 기계어 코드를 내보내는 사업을 하고 있습니다... 그리고 asm은 이미 기본적으로 그 코드입니다!

여기서 진전이 없는 이유는 아무도 이 문제를 해결하는 데 시간을 투자하지 않기 때문입니다. 그것은 기능을 안정화하는 좋은 이유가 아닙니다.

이 스레드를 읽는 동안 아이디어가 생겨 게시해야했습니다. 오래된 게시물에 답하는 것이라면 죄송하지만 그만한 가치가 있다고 생각했습니다.

@main-- 말했다:

두 최적화 모두 확실히 더 나은 처리량(특히 하이퍼스레딩의 경우)을 제공하지만 내가 달성하기를 바랐던 대기 시간 감소는 아닙니다. 나는 결국 그 실험을 위해 nasm으로 떨어졌지만 내장 코드에서 일반 asm으로 코드를 다시 작성해야 하는 것은 불필요한 마찰이었습니다. 물론 나는 옵티마이저가 일부 고급 벡터 API를 사용할 때 명령어 선택이나 상수 폴딩과 같은 것들을 처리하기를 원합니다. 그러나 사용할 명령을 명시적으로 결정했을 때 컴파일러가 이를 어지럽히는 것을 정말로 원하지 않습니다. 유일한 대안은 인라인 asm입니다.

아마도 인라인 asm 대신에 여기에서 우리가 정말로 필요한 것은 옵티마이저에게 "이것을 처리량을 위해 최적화", "지연을 위해 이것을 최적화", "바이너리 크기에 맞게 이것을 최적화"라고 알려주는 LLVM에 대한 기능 속성입니다. 나는 이 솔루션이 업스트림이라는 것을 알고 있지만, 이것은 당신의 특정 문제를 자동으로 해결할 뿐만 아니라(낮은 대기 시간을 제공하지만 그렇지 않으면 알고리즘의 동형 구현을 제공함으로써), 또한 Rust 프로그래머가 성능 특성을 보다 세밀하게 제어할 수 있게 해줍니다. 그들에게 중요합니다.

@felix91gr 그것은 인터럽트 핸들러와 같이 정확한 명령어 시퀀스를 방출해야 하는 사용 사례를 해결하지 못합니다.

@mark-im 물론 아닙니다. 그래서 제가 직역을 했습니다! 🙂

내 요점은 인라인 asm 기능을 사용하여 "컴파일러가 내가 필요로 하는 것과 반대되는 방식으로 최적화"(이 경우 고전적인 방식: 대기 시간 대 처리량)를 해결할 수 있지만 아마도 그 사용 사례는 보다 세분화된 최적화 제어를 통해 더 나은 서비스를 제공받을 수 있습니다. :)

참조 https://github.com/CraneStation/cranelift/issues/444#issuecomment -531574394

인라인 어셈블리에 대한 향후 변경 사항에 비추어 이 문제의 대부분의 논의는 더 이상 관련이 없습니다. 따라서 우리가 가지고 있는 인라인 어셈블리의 각 유형에 대한 두 가지 개별 추적 문제를 위해 이 문제를 마무리하겠습니다.

• LLVM 스타일 인라인 어셈블리에 대한 추적 문제( llvm_asm ) #70173
• 인라인 어셈블리에 대한 추적 문제( asm! ) #72016