+1! 적절한 컴파일러에 내장된 Avr 녹은 매우 유용할 것입니다. 이제 버그가 거의 없습니다.

버그가 완전히 없는 것은 아닙니다. :)

백엔드 wrt 버그의 상태에 대한 일부 정보를 포함하도록 설명을 업데이트하겠습니다.

거의 😄. 커플만 가자

일반적으로 우리는 유지 관리 부담을 주지 않는 한 Rust-lang/rust의 업스트림 플랫폼을 매우 환영합니다! 당신이 생각하고 있는 몇 가지 구체적인 생각:

• LLVM 커밋을 자주 선택하는 것은 괜찮습니다. 여러분도 이미 몇 번 프로세스를 거쳤을 것입니다. :)
• 컴파일러 rt에 내장 함수가 없어도 문제가 없습니다. 컴파일러 내장 프로젝트를 통해 Rust에서도 내장 함수를 구현할 수 있습니다.
• 당신이 가지고 있는 패치는 꽤 좋아 보이지만 libcore의 다양한 #[cfg] 를 통해 더 많은 작업을 하고 싶다고 생각합니다. 이러한 항목은 "LLVM의 버그"로 인해 누락되었거나 AVR에서 근본적으로 지원되지 않기 때문에 누락된 것입니까? 전자는 어떻게든 "LLVM을 수정"하여 가장 잘 수행되는 반면 후자는 일을 더 까다롭게 만듭니다.

일반적으로 현재 우리는 libcore/libstd의 동일한 균일 인터페이스를 가진 모든 플랫폼을 보유하고 있지만 계속해서 더 많은 플랫폼을 선택함에 따라 이것이 사실인지는 확실하지 않습니다.

가지고 있는 패치는 꽤 좋아 보이지만 libcore의 다양한 #[cfg]를 통해 더 많은 작업을 하고 싶다고 생각합니다. 이러한 항목은 "LLVM의 버그"로 인해 누락되었거나 AVR에서 근본적으로 지원되지 않기 때문에 누락된 것입니까?

LLVM의 버그 때문입니다.

내 생각에 유일한 질문은 i128 / u128 유형의 지원에 관한 것입니다. AVR의 경우 이러한 유형이 실제로 유용하지 않다고 생각합니다. i128 에서 지원 libcore 현재 버그로 인해 주석 만이 아니라 테스트 코드 경로하지 않고, 정말 AVR과 같은 레지스터 할당을 행사 같은 다른 발견되지 않은 버그가있을 수 있습니다 만 32바이트 가치의 범용 레지스터가 있습니다.

AVR에서 i128 사용할 수 있을 가능성은 여전히 ​​높지만 백엔드에서 유발하는 특정 문제에 대해서는 잘 모릅니다.

가장 좋은 방법은 libcore가 수정 없이 컴파일되거나 최소한 수정 없이 실제로 한 번 패치를 제안하는 것이라고 생각합니다.

가장 좋은 방법은 libcore가 수정 없이 또는 최소한 수정 없이 컴파일되면 실제로 패치를 제안하는 것이라고 생각합니다.

나에게 합리적으로 들린다!

내 생각에 유일한 질문은 i128/u128 유형의 지원에 관한 것입니다. AVR의 경우 이러한 유형이 실제로 유용하지 않다고 생각합니다.

AVR에서 i128 를 지원하지 않는 것에 대한 나의 주된 두려움은 AVR 또는 기타 임베디드 플랫폼과의 호환성을 위해 128비트 정수 채택에 냉각 효과가 있다는 것입니다. 예를 들어 128비트 정수를 사용하는 라이브러리가 있는 경우 이를 사용하려는 AVR 사용자는 사용 중단 문제를 제출합니다. 이것은 128비트 정수를 이식성을 위해 노력하는 Rust 코드에서 사용하기에 "안전하지" 않게 만들 수 있습니다.

AVR 또는 기타 임베디드 플랫폼과의 호환성을 위해 128비트 정수 채택 시 냉각 효과

나는 그것이 여기에서 끔찍하게 큰 거래라고 생각하지 않습니다. 소형 임베디드 장치에는 이미 거대한 제한 사항(stdin/stdout 없음, 일반적으로 할당자 없음 등)이 있어 임의의 라이브러리에 놓기가 정말 어렵습니다. 최근에 AVR GCC의 double 가 실제로 float 의 별칭이라는 것을 알게 되었습니다! 우리가 그 기이함을 유지할 것인지 아닌지는 모르겠지만 i128 보다 더 큰 상자에 영향을 미칠 것입니다.

나는 우리가 no-std에서 하는 것과 같이 임베디드에 적합한 크레이트를 만드는 데 사용되는 특별한 기능을 항상 갖게 될 것이라고 생각합니다.

stdin / stdout 없음, 일반적으로 할당자 없음 등

#![no_std] 생태계를 설명하고 있습니다. 이 생태계를 대상으로 하는 라이브러리가 있습니다. 그리고 그 생태계에 대한 일반적인 규칙은 i128 도 포함하는 libcore 를 주어진 것으로 간주하는 것입니다. i128 지원하지 않는 각 대상은 x86 제품군이 그다지 관련성이 없는 전체 Rust 생태계의 하위 집합 내에서 임베디드 대상의 "시장 점유율"이 더 크기 때문에 이 생태계 내에서 더 큰 냉각 효과를 가집니다. .

우리가 그 이상함을 유지할 것인지 아닌지는 모르겠지만, 그것은 i128보다 훨씬 더 크레이트에 영향을 미칠 것입니다.

흥미로운! f64 별칭을 f32 하거나 제공하지 않으면 생태계에 더 많은 영향을 미칠 것이라는 데 동의합니다. 그러나 일관성을 유지하기 위해 노력할 수 있다면 왜 하지 말아야 합니까? i128 를 구현하는 것은 확실히 가능합니다.

i128을 구현하는 것은 확실히 가능합니다.

물론, AVR용으로 i128을 구현해야 한다고 명확하게 언급하지 않았음을 실제로 i128 를 사용 하는 모든 코드는 고통의 세계에 들어갈 것입니다.

그러나 일관성을 유지하기 위해 노력할 수 있다면 왜 하지 말아야 합니까?

무엇 과의 일관성이 문제입니다. GCC( f64 == f32 ) 또는 다른 모든 Rust 타겟( f64 != f32 )과의 일관성?

#![no_std] 생태계를 설명하고 있습니다.

네, 그래서 제가 "no-std에서 하는 것처럼 내장형에 적합한 크레이트를 만드는 데 사용되는 특수 기능"이라고 말한 것입니다. 😇

우리가 16비트 usize 패치를 처음 출시한 이후로 제 마음 속에 있던 더 큰 문제는 기본적으로 Rust와 Rust 프로그래머가 usize 가 "네이티브"라고 가정하는 경향이 있다는 것입니다. 레지스터의 크기. AFAIK, 이것은 Rust가 대상으로 하는 다른 모든 플랫폼에 해당되지만 AVR에는 해당되지 않습니다.

무엇과의 일관성이 문제입니다. GCC(f64 == f32) 또는 다른 모든 Rust 타겟(f64 != f32)과의 일관성?

f64 라는 이름

여기서 좋은 점은 128비트 정수에 대한 우려를 볼 수 있습니다. 사용을 권장해서는 안 되지만 지원해야 한다고 생각합니다. i128 유형에 대한 특성 impls와 같은 기능 플래그를 추가해야 하는 상자를 보고 싶지 않습니다. 사용하지 않는 i128 항목은 모두 링커에서 제거해야 하므로 이것은 실제로 문제가 되지 않습니다.

f32/64 문제는 흥미로운 문제입니다. f64를 실제로 64비트로 만드는 것에 대한 나의 주요 관심사는 C FFI가 매우 부서지기 쉽다는 것을 의미한다는 것입니다. 개발자가 AVR-GCC가 32비트 더블을 사용한다는 것을 모르는 경우 FFI를 통한 호출은 초기화되지 않은 메모리 또는 세그폴트를 읽을 수 있습니다.

사용자가 대신 libc 크레이트의 유형을 사용하기를 기대함으로써 이 문제를 어느 정도 해결할 수 있다고 생각합니다. c_double 를 f32 로 설정하는 AVR 관련 기능을 추가할 수 있습니다. 사람들이 FFI 바인딩에 libc 크레이트를 사용하기를 합리적으로 기대할 수 있다고 생각합니다.

병합을 위해 기억해야 할 사항은 main() 서명에 사용된 c_int 유형을 업데이트해야 합니다. https://github.com/rust-lang/rust/pull/44906#discussion_r141843808

편집: MSP430에도 영향을 미치므로 이에 대한 문제를 열었습니다. https://github.com/rust-lang/rust/issues/44934

main() 서명에 사용

@mattico 어쩌면 내가 이상한 방식으로 일을 내 코드 중 어느 것도 Rust의 main 사용하지 않았습니다 .

#[no_mangle]
pub extern fn main() {

로 돌아가려면 아무 것도 없기 때문에 더 중요한 것은, 우리가 정말 반환 할 수 없습니다. 모든 프로그램은 영원히 실행되어야 합니다.

@mattico 유형이 AVR용 GCC와 일치하도록 libc를 수정해야 합니다.

아, 물론 main 이 우리에게 전혀 영향을 미칠지 모르겠습니다.

@shepmaster 내장되지 않은 플랫폼에서도 우리가 지금까지 잘못 알고 있었고 IR을 검사할 때 외에는 아무도 눈치채지 못했다는 점을 감안할 때 main의 argc 크기는 중요하지 않습니다. 프로세스에 표준 main() 진입점을 사용하는 일부 RTOS가 있을 수 있습니까? 어쨌든 쉽게 고칠 수 있습니다.

지금 생각해보면 수정사항을 제출하는 데 입력하는 것과 같은 시간이 걸렸을 것입니다. 😄

이 병합을 방해하는 libcore 문제뿐입니까? 노력을 어디에 집중해야 하는지 알기 위해서입니다.

내가 libcore에서 겪었던 유일한 문제는 내가 무엇을 모르고 32비트 시프팅 오류로 인해 발생하는 이상한 링커 오류입니다(내 생각에 내장 누락). 그것들이 병합을 차단하고 있는지 모르겠습니다.

chocol4te: 이 병합을 방해하는 libcore 문제뿐입니까? 노력을 어디에 집중해야 하는지 알기 위해서입니다.

예 - 여기에서 필요한 모든 작업 은 LLVM 내에서 수행

Restioson: 내가 libcore에서 겪었던 유일한 문제는 무엇인지 모르고 32비트 비트 시프팅 오류(내 생각에 내장 누락)로 인한 이상한 링커 오류입니다.

AVR 백엔드 초크를 만드는 모든 코드가 주석 처리되어 있기 때문입니다. :)

Restioson: 그것이 병합을 차단하고 있는지 모르겠습니다.

직접은 아니지만 백엔드가 병합되기 전에 수정하는 것이 좋습니다. 병합하기 전에 수정해야 하는 이와 같은 정말 성가신 버그가 몇 가지 있지만 반드시 유지되는 것은 아닙니다.

@dylanmckay LLVM6이 https://github.com/rust-lang/rust/pull/47828 병합되었습니다. 이것은 이 RFC에 무엇을 의미합니까?

@kellerkindt "AVR 백엔드의 현재 문제"에 나열된 모든 문제는 여전히 사실입니다. avr-rust의 현재 HEAD가 재기반될 수 있고 흥미로운 Rust 관련 코드가 병합될 수 있지만 여전히 작동하는 코드를 얻지는 못합니다.

저는 개인적으로 여전히 찬성합니다

가장 좋은 방법은 libcore가 수정 없이 또는 최소한 수정 없이 컴파일되면 실제로 패치를 제안하는 것이라고 생각합니다.

추가 리베이스를 피하는 것이 좋지만.

개발 반년이 지난 지금, AVR에서 Rust의 현재 상태가 궁금합니다. 나는 우리 마을에서 작은 Arduino 프로젝트 그룹을 운영하고 있으며 대신 Rust를 사용할 수 있기를 _사랑_하고 싶습니다.

좋은 소식입니다!

가장 좋은 방법은 libcore가 수정 없이 또는 최소한 수정 없이 컴파일되면 실제로 패치를 제안하는 것이라고 생각합니다.

이것이 지금의 경우입니다!

현재 avr-rust 포크에는 libcore 대한 수정 사항이 없습니다.

재고 Rus에서 AVR을 지원하는 데 필요한 수정 사항은 다음과 같습니다.

• AVR 백엔드 초기화 함수 LLVMInitializeAVR{Target,TargetInfo,AsmPrinter,AsmParser, ...} 가 선언되고 호출됩니다.
• 기본 최소 avr 대상 사양 avr-unknown-unknown 이 추가되었습니다. 이것은 명시적으로 지정되지 않는 한 가장 낮은 공통 분모를 구축하는 avr-gcc의 기본 동작을 모델링합니다. -mmcu=<avr mcu name> 인수를 명시적으로 지원하는 avr-gcc 와 달리 AVR에 AVR 관련 명령줄 인수가 추가되지 않았습니다. 즉, 모든 프로젝트에 대해 사용자 지정 대상 사양 JSON 파일을 작성해야 합니다. 이것은 많은 Rust 임베디드 프로젝트의 경우입니다.
• 포크에서 AVR LLVM 백엔드는 항상 기본 Rust 체크아웃에서 컴파일 및 링크되며 config.toml.example 파일에 추가됩니다. AVR은 기본적으로 업스트림 Rust에 포함되어야 합니까, 아니면 옵트인해야 합니까?
• 모든 새 대상에 필요한 경우 컴파일러에 AVR 특정 논리 추가
• "avr-interrupt" 호출 규칙이 추가되었습니다. 이것은 extern "avr-interrupt" fn my_isr_handler() { .. } 합니다. 이것은 안정화되기 위해 아마도 RFC 프로세스를 거쳐야 할 것입니다. 그러나 제가 틀릴 수 있습니다.
• CPU에 대한 조건부 컴파일 지원, #[cfg(target_cpu = "...")] 가 추가되었습니다. 구현은 여기 에서 찾을 수 ruduino 상자는 실리콘에서 지원되는 모든 IO, 레지스터 및 모듈을 노출하는 장치별 모듈을 조건부로 포함할 수 있습니다. 이것은 업스트림 전에 RFC 프로세스를 거쳐야 합니다.

이제 백엔드를 비실험 상태로 승격하는 것과 관련하여 RFC를 LLVM-dev에 보낼 때가 된 것 같습니다.

여기 에서 업스트림 Rust에서 avr-rust로의 전체 변경 사항을 볼 수 있습니다.

우리가 현재 선별한 지난 두 달 동안의 LLVM 패치가 몇 개 있지만, 다른 모든 대상에 사용되는 LLVM 버전과 엠스크립튼 버전의 LLVM을 분리하려는 업스트림 Rust의 노력으로 정말 쉽게 가져올 수 있습니다. rust-lang/llvm repo에서 이러한 변경 사항은 이제 정기적으로 업스트림에 업데이트됩니다.

우리가 가지고 있는 <4개의 체리 픽 LLVM 패치는 현재 업스트림 LLVM에서 검토 중이므로 검토자가 충분한 시간을 찾으면 해당 패치는 자동으로 업스트림 Rust로 이동합니다. Upstream Rust에는 대상별 Rust별 패치도 있으므로 체리 선택 LLVM 패치는 아마도 avr-rust upstream 병합을 위한 차단기가 아닐 것입니다.

AVR에서 Rust의 상태에 대한 업데이트가 있습니까?

또한 알고 싶어! 지금은 STM32 블루 알약을 해킹하는 것으로 전환했지만 녹에서 avr에 대한 지원이 준비되면 확실히 arduino로 돌아가고 싶습니다.

@slowtec 은 또한 AVR 프로젝트에 Rust를 사용하는 것을 좋아할 것이며 물론 많은 프로덕션 코드를 공개할 것입니다. :)

범프, 지원이 공식화되는 것을 보고 싶습니다. 프로젝트에 포크를 사용하려고 합니다.

업데이트: 현재 포크를 최신 버전의 Rust(avr-rust/rust#137)로 업그레이드하고 있습니다. 우리가 발견한 두 가지 버그가 있습니다.

LLVM 오류: 레지스터 할당 중 레지스터 부족

이것은 llvm/ llvm-project@45eb4c7e55341c0b83a21ddecc092e273795eda의 LLVM 트렁크에서 수정되었습니다

LLVM 오류: 선택할 수 없음: t2: i16 = addrspacecast[1 -> 0] undef:i16
t1: i16 = undef
기능: _ZN4core3ptr87_$LT$impl$u20$core..fmt..Debug$u20$for$u20$unsafe$u20$fn$LP$A$RP$$u20$.$GT$$u20$Ret$GT $3fmt17h0fdf8ca7140def9b

이것은 수정하기가 더 어렵습니다. 이는 주 메모리와 프로그램 메모리에 액세스하기 위한 두 개의 개별 포인터 주소 공간이 있는 Harvard 아키텍처에서 Rust가 함수 포인터를 잘못 처리하기 때문에 발생합니다.

설명은 @ecstatic-morse가 가장 잘 합니다.

근본적인 문제는 *const T에 항상 addrspace(0)이 있다는 것입니다. 명시적 캐스트(ptr as *const T)는 여기에서 입력의 주소 공간을 보존해야 한다고 생각합니다.

버그는 함수 및 함수 포인터에 대한 std::fmt::Debug 구현에 의해 노출됩니다. Rust는 암시적으로 비트캐스트(iN -> iM 비트) 또는 필요한 경우 주소 공간 캐스트를 삽입하는 LLVM 루틴을 사용하여 addrspace(0)* i16 대상 포인터 유형으로 포인터 역참조를 내보냅니다. 함수 포인터의 경우, Rust는 addrspace(1)* i16 포인터를 코드 생성해야 합니다. 그래서 LLVM이 ( addrspacecast ) PROGMEM 포인터를 RAM 포인터에 매핑할 필요가 없습니다. 메모리 매핑이 없기 때문에 불가능한 작업입니다. 주소 공간은 겹치지 않습니다.

이 버그가 주요 차단기입니다.

나는 업스트림 Rust가 LLVM 마스터(AFAICT, 8.0 릴리스에 있음)에서 가져오기를 희망하므로 많은 체리픽을 제거할 수 있습니다.

나는 최근에 AVR 에뮬레이터를 사용하여 성공한 https://github.com/dylanmckay/avr-compiler-integration-tests/ 테스트를 얻었습니다. 이는 실제로 LLVM이 내뿜는 AVR 어셈블리를 실행하는 다른 테스트 제품군이 없기 때문에 훌륭합니다. 모든 AVR-Rust 커밋(GitLab 저장소 미러를 통해)에 대한 테스트를 실행하도록 GitLab 러너를 설정했지만 GitLab은 pull 요청에 대한 CI 빌드를 지원하지 않기 때문에 별로 유용하지 않습니다. 분기된 저장소.

@dylanmckay 업데이트에 감사드립니다. 우리 모두는 당신이 이 일에 쏟은 노력에 감사드립니다.

우리는 이제 Rust 기반 rust-lang/ rust@fb7cca33f 의 포크를 업그레이드

이 문제가 중단되었습니까?

이에 대한 업데이트가 있습니까? 주소 공간 문제로 인해 PR이 여전히 지연되고 있습니까?

@dylanmckay님 , 버그로 인해 죄송합니다. 이 문제에 대한 업데이트가 있습니까?

안녕하세요 여러분, 여기 저로부터 몇 가지 의견이 있습니다.

체리 따기 수정

libcore 작업에 필요한 거의 모든 수정 사항이 LLVM 마스터로 업스트림되었으며 현재 rust-lang/llvm 포크에 있습니다. 어제 저는 AVR 포크를 1.39.0(avr-rust/rust#155)으로 업데이트하기 위해 PR을 시작했습니다. 저는 아직 거기에 없는 하나의 수정 사항만 선택하면 되었습니다 .

libcore는 수정 없이 컴파일할 수 없습니다.

AVR을 사용하기 위해 더 이상 사용자 지정 libcore 포크가 필요하지 않습니다. 현재 avr-rust 포크에서 libcore 에 대한 수정 사항은 하나만 있습니다. - avr-rust/ rust@44240ac59c5949b8a9fd191f5cd666d0206fbe85 - 올바른 IR 생성을 위해 포인터 캐스트를 다시 작성하십시오.

우리는 AVR-Rust 바이너리를 컴파일하기 위해 xargo 에 의존하고 있습니다. 이것은 std-aware Cargo 이니셔티브가

프로그램 메모리가 아닌 '호출' 액세스 RAM 이외의 함수 포인터에 대한 모든 작업(avr-rust#68)

이 문제가 해결되었습니다.

32비트 시프트는 존재하지 않는 컴파일러-rt 루틴에 대한 호출을 생성합니다(avr-llvm/llvm#163).

이것은 여전히 ​​고통스러운 문제입니다. 최선의 수정은 LLVM AVR 백엔드에 사용자 정의 낮추는 코드를 작성하여 이러한 순수 어셈블리로의 전환을 낮추고 컴파일러-rt 또는 libgcc에 대한 ABI 종속성을 제거하는 것이라고 생각합니다. 생성된 코드 크기가 얼마나 커질 수 있는지 확실하지 않습니다. 좋은 생각이 아닐 수도 있습니다.

업스트림 전 질문

RFC 및 불안정한 호출 규칙

이 댓글을 스레드에 올렸습니다

"avr-interrupt" 호출 규칙이 추가되었습니다. 이것은 extern "avr-interrupt" fn my_isr_handler() { .. }를 허용합니다. 이것은 안정화되기 위해 아마도 RFC 프로세스를 거쳐야 할 것입니다. 그러나 제가 틀릴 수 있습니다.

RFC 프로세스를 거치지 않고 불안정한 호출 규칙을 추가할 수 있습니까?

현재 #![feature(abi_avr_interrupt)] 기능 게이트 아래에 "avr-interrupt" 및 "avr-non-blocking-interrupt" 가 있습니다. 향후 안정화 RFC를 기다리는 동안 불안정한 호출 규칙으로 업스트림될 수 있습니까?

빌드봇

LLVM 백엔드를 업스트림하려면 해당 백엔드에 대한 테스트를 실행하고 유지 관리하는 전용 빌드봇을 설정해야 합니다. 이것이 Rust의 경우입니까? 테스트 스위트가 푸시할 때마다 AVR 모드에서 실행되도록 하려면 어떻게 해야 합니까? WASM과 같은 다른 백엔드는 무엇을 했습니까?

분포

"avr-rust fork upstream 병합"은 단순히 두 개의 포크를 하나로 병합하지만 여전히 소스에서 빌드해야 함을 의미합니까? 백엔드를 배포하는 것이 가능하지만 야간에만 가능합니까? 다른 백엔드는 무엇을 했습니까?

그 외에는 avr-rust 특정 패치가 매우 얇으며 요즘은 해킹이 없습니다.

전체 패치 세트는 https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support에서 볼 수 있습니다.

내 WIP 1.39.0 리베이스 패치 세트(대부분 동일)는 https://github.com/rust-lang/rust/compare/master...avr-rust :avr-support-1.39.0-4560ea788c에서 찾을 수 있습니다. . 이것은 앞으로 며칠 내에 avr-rust/master에 병합되어야 합니다.

이것을 차단하는 구체적인 것은 생각나지 않습니다. 아마도 패치를 제출하고 어떻게 진행되는지 볼 시간이 된 것 같습니다.

https://github.com/rust-lang/rust/issues/44036

위에서 이 문제를 언급했지만 AVR 백엔드의 업스트림을 차단한다고 생각하지 않습니다. 우리는 AVR 없이도 작동하고 유용한 Rustc 버전을 출시할 수 있어야 합니다. 우리가 다시 할 수 있는 해결 방법과 해킹이 있다고 확신합니다. 백엔드가 가상으로 병합된 후와 API를 쿼리하는 공식 대상 CPU가 공식 Rust에 도착하기 전에 AVR 상자에서 장치 감지.

그는 산다! @dylanmckay 업데이트, 흥미로운 진행에 감사드립니다.

잘했어 @dylanmckay! 정보를 제공해 주셔서 감사합니다.

주제에서 조금 벗어나지만: avr용 rustc가 C 라이브러리로 FFI를 수행할 수 있습니까?
이미 avr에 사용할 수 있지만 C/C++로 작성된 성숙한 라이브러리가 많이 있습니다.
그것들을 위한 약간의 러스트 스타일 래퍼를 만들고 우리의 러스트 avr 프로젝트에서 재사용할 수 있다면 좋을 것입니다.

Rust는 이미 일반적으로 C로 FFI를 할 수 있습니다.

예, 정말 훌륭합니다! 그러나 문제는 이것이 rust-avr로 변환됩니까?

AVR용 LLVM의 C ABI가 gcc의 ABI와 일치하는 한 작동해야 합니다.

RFC 프로세스를 거치지 않고 불안정한 호출 규칙을 추가할 수 있습니까?

내 투표는 AVR 호출 규칙을 지원하기 위해 변화로 기본적으로 그냥 그들에게 이름을 부여하고 LLVM 번호에 매핑되고, yes입니다. 불안정한 규칙에 대한 지원이 이미 있으므로 기본적인 코드 변경이 필요하지 않습니다.

LLVM 백엔드를 업스트림하려면 해당 백엔드에 대한 테스트를 실행하고 유지 관리하는 전용 빌드봇을 설정해야 합니다. 이것이 Rust의 경우입니까? 테스트 스위트가 푸시할 때마다 AVR 모드에서 실행되도록 하려면 어떻게 해야 합니까? WASM과 같은 다른 백엔드는 무엇을 했습니까?

Rust의 티어 시스템은 약간 느슨하게 정의되어 있지만 AVR 전용 코드 를 병합 Tier 3 가 됩니다. 즉, 자동으로 빌드되거나 테스트 되지 않고 코드에 매달려 있을 뿐입니다. 최소한 이는 해당 파일이 컴파일러 변경 사항에 따라 최신 상태로 유지된다는 것을 의미합니다.

"avr-rust fork upstream 병합"은 단순히 두 개의 포크를 하나로 병합하지만 여전히 소스에서 빌드해야 함을 의미합니까?

내가 아는 한, 하나의 커밋 을 PR로 제출하는

아마도 패치를 제출할 시간입니다

나도 그렇게 생각해.

@edvorg 주제 IMO에 매우

주제에서 조금 벗어나지만: avr용 rustc가 C 라이브러리로 FFI를 수행할 수 있습니까?
이미 avr에 사용할 수 있지만 C/C++로 작성된 성숙한 라이브러리가 많이 있습니다.

네.. 대부분. AVR 백엔드에 의해 구현된 AVR 호출 규칙은 AVR-GCC( 여기에 문서화됨)와 일치하도록 설계되었습니다. 몇 가지 단점이 있지만 검토해야 하는 LLVM 패치 D68524 를 통해 수정해야 합니다.

Rust 호출 사이트는 항상 Rust 또는 avr-clang 컴파일된 함수(avr-clang C가 Rust 프론트엔드와 동일한 extern "C" 호출 규칙 구현을 사용하기 때문에) 및 AVR-GCC와의 상호 작업을 _should_ 작동하도록 올바르게 호출할 수 있습니다. 특히 단순한 함수 서명의 경우에는 질식할 수 있습니다(자세한 내용은 D68524 설명 참조).

이에 대한 업데이트가 있습니까?
그냥 궁금합니다.

LLVM AVR 백엔드를 공식 백엔드로 만들기 위해 제출된 요청 - https://reviews.llvm.org/D75099

@dylanmckay 수락되면 이 문제를 마무리하는 데 남은 부분은 무엇입니까?

@dylanmckay 수락되면 이 문제를 마무리하는 데 남은 부분은 무엇입니까?

기술적으로 Rust는 공식 백엔드와 실험적 백엔드 모두에서 작동합니다. 백엔드의 대부분을 업스트림하기 위해 #69478을 올렸습니다.

AVR을 Tier 3 대상으로 병합하는 것이 AVR이 공식 LLVM 백엔드가 되는 것을 전제로 하는지 잘 모르겠습니다. 환영합니다.

그것에 대해 생각해보면, LLVM의 공식 대 실험적 구별은 Rust의 계층 시스템에 매핑될 수 있으며, 그 중 Rust에는 3개의 계층이 있고 LLVM에는 2개의 계층이 있습니다. LLVM 공식 백엔드는 기본적으로 테스트 제품군 및 공식 릴리스에 포함된 Tier 1 및 2의 혼합에 해당합니다. 내가 말할 수 있는 한 LLVM 실험적 백엔드는 의미상 Rust Tier 3 백엔드와 동일합니다. 소스 트리에 포함, 기본적으로 릴리스에 포함되지 않음, 기본 CI 테스트에 포함되지 않음 등

그런 다음 이 문제를 마무리하는 데 남은 유일한 부분은 #69478의 코드 리뷰에 나오는 부분일 것입니다.

tl;dr AVR 백엔드가 병합되면 rust-lang/rust#69478의 Tier 3 업스트림 대상이 되어 포크가 종료됩니다.

avr-rust/rust 포크와 #69478의 유일한 차이점은 AVR 포크에는 있지만 업스트림에는 없는 target_cpu cfg 플래그입니다. 초기 PR에서 생략했습니다.

나머지 조각은 무엇입니까

다양한 유형의 코드에 대한 잘못된 컴파일이 여전히 많다고 확신하기 때문에 여전히 더 많은 사람들이 시도하고 버그를 최소화하고 수정해야 합니다.

일반적으로 구식 포크를 컴파일하는 대신 매일 밤 일반 Rust를 얻을 수 있기 때문에 위로 올라가면 사람들이 시도하도록 막대가 낮아질 것입니다.

Tier 3 대상으로 업스트림되면 AVR 개발이 화물의 -Z build-std 기능과 함께 작동합니까, 아니면 xargo가 필요합니까? Rust와 함께 제공되는 LLD는 AVR을 지원합니까, 아니면 gnu 링커가 필요합니까?

AVR 개발은 화물의 -Z build-std 기능과 함께 작동합니까, 아니면 xargo가 필요합니까? Rust와 함께 제공되는 LLD는 AVR을 지원합니까, 아니면 gnu 링커가 필요합니까?

그것이 작동하지 않을 것이라고 말할 수 는 없지만 내가 한 모든 것은 Xargo와 GNU 링커를 사용했습니다.

GNU 링커는 Windows에서 설정하기 어렵고 xargo를 설치하려면 도구가 하나 더 필요합니다. 그래서 제가 묻습니다.

Rust와 함께 제공되는 LLD는 AVR을 지원합니까, 아니면 gnu 링커가 필요합니까?

LLD는 AVR 연결에 대한 매우 기본적인 지원만 제공하며 아직 실제 프로그램을 연결할 수 없습니다. 따라서 avr-ld 가 필요합니다.

그것이 내가 묻는 이유입니다.

실수하지 마십시오. 또한 그것이 올바른 최종 목표라고 생각합니다. 현재의 세계 상태가 아닐 수도 있습니다. 솔직히, 나는 오버 헤드를 낮추고 낮추게되어 기쁩니다. 병합하는 것은 이를 위한 첫 번째 단계일 뿐입니다.

이제 AVR 백엔드가 공식 LLVM 대상으로 활성화되었습니다. 기본적으로 AVR을 포함하는 첫 번째 LLVM 릴리스는 약 6개월 후에 LLVM 11이 될 것입니다.

멋진! 모든 노력에 감사드립니다.

아주 멋져!

이 놀라운 성과에 @dylanmckay 를 축하합니다. 커뮤니티는 이에 대한 귀하의 노력에 감사드립니다.

나는 잠시 동안 이 문제를 추적해 왔으며 이것이 대부분 주제를 벗어난다는 것을 알고 있지만 이것이 소스가 아닌 평균 사용자에게 무엇을 의미하는지 관심이 있습니다... 이것을 사용하여 기본 Rust로 Arduino Uno를 실행하고 있습니까? 나는 Rust가 충분한 보호 기능을 가지고 있기 때문에 이것에 가장 관심이 있습니다.

@Jimmio92 제가 알기로는 그렇습니다. "예, 복잡합니다"와 같이. 또는 특별히 복잡하지 않더라도 최소한 길고 지루합니다. 소스에서 Rust 컴파일러의 사용자 정의 포크를 빌드해야 하기 때문에 소스에서 LLVM을 빌드해야 합니다. 모든 것이 잘되면 보통 몇 시간이 걸립니다

_{그러나 LLVM에 대한 제 개인적인 경험은 시스템의 무언가가 마음에 들지 않는다는 것입니다. 따라서 성공하거나 포기할 때까지 필연적으로 설치 경로와 사용자 정의 라이브러리를 마사지하게 됩니다.}

위의 (훌륭한) 뉴스가 의미하는 바는 LLVM의 개발자가 이제 공식적으로 AVR을 목표로/지원하고 있으며(?) LLVM의 다음 릴리스에는 AVR 지원이 포함될 것입니다. 이제 Rust가 단기간에 AVR도 지원하거나 지원할 것이라고 말할 수는 없습니다 . 문제와 위의 댓글을 보면 AVR 지원이 기본 Rust 도구 체인에서 "그냥 작동"할 때까지 많은 작업이 필요하다는 것을 알 수 있습니다.

LLVM 마스터에서 Rust LLVM 포크로 AVR 수정 사항을 선별하여 볼 수 있는 프로세스/예가 있습니까?

또한 Rust는 여전히 LLVM 마스터를 추적합니까? 외관상으로는 현재 릴리스와 일부 체리 선택 수정 사항을 추적합니다. LLVM 버전을 마스터로 업데이트하는 PR이 계속 허용됩니까?

@dylanmckay

또한 Rust는 여전히 LLVM 마스터를 추적합니까?

당신이 눈치 챘을 때 그것은 지금 릴리스를 추적합니다.

LLVM 버전을 마스터로 업데이트하는 PR이 계속 허용됩니까?

나는 그렇게 생각하지 않지만 cc @nikic

@dylanmckay 10.0 릴리스와 비교하여 Rust의 LLVM 포크에 많은 수정 사항이 있습니다. https://github.com/rust-lang/llvm-project/commits/rustc/10.0-2020-05-05

LLVM 마스터에서 Rust LLVM 포크로 AVR 수정 사항을 선별하여 볼 수 있는 프로세스/예가 있습니까?

여기에 지침이 있습니다: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#bugfix -updates

또한 Rust는 여전히 LLVM 마스터를 추적합니까? 외관상으로는 현재 릴리스와 일부 체리 선택 수정 사항을 추적합니다. LLVM 버전을 마스터로 업데이트하는 PR이 계속 허용됩니까?

Rust는 현재 LLVM 릴리스를 추적하고 있습니다. 이를 통해 사람들은 해당 clang 버전으로 언어 간 LTO를 쉽게 수행할 수 있기 때문입니다. 따라서 여기의 기본 대답은 아마도 "아니오"입니다.

즉, LLVM 10 컴파일 타임 회귀를 완화하기 위해 LLVM 마스터로 업데이트하는 것에 대한 논의가 있었습니다. 현재 평가 목적으로 작업 중입니다. 나는 이것이 일어나지 않을 것이라고 가정하고 LLVM 10 포크에 대해 체리 픽을 제출하는 것이 더 안전하다고 생각합니다(많은 것이 있습니까?)

포크가 병합되었습니다! 오늘 오후에 적절한 업데이트를 작성하겠습니다.

https://github.com/rust-lang/rust/pull/69478

오늘 오후에 적절한 업데이트를 작성하겠습니다.

나는 그 업데이트에 관심이 있습니다. @dylanmckay 어디에 게시할 계획인가요?

나는 말 그대로 몇 년 동안 Rust 생태계에 이 추가를 간절히 기다리고 있습니다! 그러나 이것을 마스터에서 사용하려는 순진한 시도는 결함이 있는 것 같습니다.

나는 ./x.py build 표준 master 으로 링크된 다음 avr-rust/blink 예제를 빌드하려고 시도했습니다( llvm_asm! 를 사용하도록 src/main.rs 업데이트 후). llvm_asm! ):

RUST_TARGET_PATH=`pwd`
XARGO_RUST_SRC=/home/nixpulvis/Projects/rust

rustup run master xargo build --target avr-atmega328p --release

이것은 다음과 함께 실패합니다.

error: no matching package named `core` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `sysroot v0.0.0 (/tmp/xargo.oXlxlujoXvXJ)`
error: `"cargo" "build" "--release" "--manifest-path" "/tmp/xargo.oXlxlujoXvXJ/Cargo.toml" "--target" "avr-atmega328p" "-p" "core"` failed with exit code: Some(101)
note: run with `RUST_BACKTRACE=1` for a backtrace

아직 누락된 구성이 필요하다고 가정합니다.

@nixpulvis 참조 https://github.com/rust-lang/rust/issues/44052#issuecomment -591396417

libcore가 잘못 컴파일된 것의 일부이므로 지금은 아무 것도 작동하지 않을 것으로 예상됩니다.

AVR Rustc 포크가 업스트림에 병합되었습니다.

업스트림 포크는 아직 일반적으로 사용할 수 없습니다. 먼저 발생해야 할 몇 가지 사항이 있습니다.

AVR LLVM 업스트림에서 Rust가 아직 선별할 필요가 없는 문제를 수정했습니다.

@nikic 의 질문에 답하기

저는 스크립트를 사용하여 LLVM 업스트림에서 로컬 포크로 _all_ AVR 커밋을 자동으로 선택했습니다.
이것은 큰 망치이며 불필요한 수정 사항이 있을 것입니다. 백엔드를 사용할 수 있게 되기 전에 업스트림 Rust로 가져와야 하는 업스트림 LLVM 수정 사항이 있습니다. 그들은 걸러내고 상류 Rust로 체리 피킹해야 합니다.

업스트림 Rust 마스터 브랜치에서 AVR LED 깜박임 프로그램 컴파일

업스트림 노력이 이제 몇 달 동안 진행됨에 따라 다운스트림 avr-rust 포크
아직 Rust의 특히 오래된 버전에 있습니다. 그 이후로 LLVM 주장 오류를 일으키지 않고 AVR을 지원하기 위해 일반화가 필요한 업스트림 Rust에 최소한 한 가지 변경 사항이 있었습니다. 이 문제를 해결하기 위해 pull request #73270을 열었습니다.

AVR에 대한 변경이 필요한 업스트림 Rust에 다른 변경 사항이 있는지 확실하지 않습니다.

깜박임 프로그램이 작동하면 그 시점에서 업스트림 AVR 지원이 사용/실험 준비가 되어야 하기 때문에 다른 업데이트를 게시하겠습니다.

AVR 통신이 발생/게시되어야 하는 위치

@wezm 좋은 지적을 하셨습니다. 업데이트를 위한 "축복받은" 커뮤니케이션 채널이 반드시 필요한 것은 아닙니다. 이 티켓은 잘 사용되었지만 곧 부득이하게 닫힐 것입니다.

AVR-Rust Gitter 채널은 현존하는 가장 자연스러운 선택입니다. 나는 메일링 리스트라는 아이디어를 좋아한다(그러나 나는 가능하다면 메일 서버를 호스팅한다는 아이디어는 좋아하지 않는다). Gitter 채널에는 토론이 있으므로 메일링 리스트와 같은 것이 도움이 될 것입니다.
공지/업데이트를 중앙 집중화하려면 블로그를 설정하는 것이 좋습니다. 캐쥬얼한 업데이트를 원하는 분들이 놓치지 않도록 "공식 매체"를 갖고 싶습니다. 블로그는 새 게시물을 지속적으로 확인해야 하는 반면 메일링 리스트는 본질적으로
관심있는 모든 분들. 제안을 환영합니다.

열린 질문

• avr-rust 포크의 GitHub 문제를 업스트림 Rust 저장소로 옮겨야 하나요?
  ** 그럼에도 불구하고 업스트림 저장소에서 새로운 문제를 제기해야 합니다. 이전 문제 추적기를 종료해야 합니다.
  
  
  
  • AVR로 Rust를 컴파일하기 위한 지침은 어디에 있어야 합니까?
  
  

미래를 위한 가장 중요한 것들(읽기: 우선순위)

• AVR Rust 바이너리의 패키징 및 배포. Rust를 컴파일하는 것은 일반 사용자에게 큰 골칫거리가 될 수 있습니다.
  많은 배포판에는 특정 워크플로에서 때때로 문제가 있는 것 같습니다. 여러 OOM 오류가 다음과 같이 잘못 보고되었습니다.
  컴파일러 버그. 진입 장벽은 불필요하게 높으며 낮아야 합니다. 다운로드하고 이동하세요.
  추적 https://github.com/avr-rust/rust/issues/162
• "지원되는" 또는 최소한 테스트된 구성 목록 작성. (rustc version, Xargo version) 테이블이 필요하므로
  Xargo가 의존하는 비공개 Rust API에 대한 변경 사항은 업그레이드 시 AVR Rust 도구 체인을 손상시키지 않습니다.
  Xargo가 유지 관리 모드에 있습니다 - 화물 xbuild가 상당히 제한적인 것 같습니다(몇 주 전에 시도했지만 이유가 기억나지 않음).
  우리는 Xargo를 포크해야 할 수도 있습니다. 도구를 Cargo에 직접 추가하는 것이 더 나을 수 있습니다(이에 대한 추적 문제가 있음).
• 다운로드 링크를 포함하여 프로젝트에 대한 일종의 홈페이지 설정
• 통합 테스트(에뮬레이트/시뮬레이션된 AVR에서 각 커밋 시)

당분간은 더 나은 매체를 찾을 수 있을 때까지 이 GitHub 문제에 업데이트를 다시 게시하겠습니다. Gitter에도 게시하겠습니다.

공지/업데이트를 중앙 집중화하려면 블로그를 설정하는 것이 좋습니다. 캐쥬얼한 업데이트를 원하는 분들이 놓치지 않도록 "공식 매체"를 갖고 싶습니다. 블로그는 새 게시물을 지속적으로 확인해야 하는 반면 메일링 리스트는 본질적으로
관심있는 모든 분들. 제안을 환영합니다.

내 개인적인 취향은 블로그(RSS 피드 포함)를 강력히 선호합니다. 블로그는 일반적으로 검색 엔진 결과에 더 잘 나타나며 메일링 리스트 스레드보다 링크하기에 더 좋습니다. RSS 피드는 확인/통지 측면을 해결합니다.

최고의 장소인지 100% 확신할 수는 없지만 Embedded WG 블로그가 있습니다. 커뮤니케이션을 위한 노력이 적게 드는 채널일 수 있습니다.

https://rust-embedded.github.io/blog/

아마도 트위터 계정도? 새로운 블로그 게시물을 공유하는 데 사용할 수 있습니다(최신 상태를 유지하기 위해).

내장된 작업 그룹이 여기에서 기꺼이 도움을 줄 것이라고 생각합니다. 트위터 계정 @rustembedded 가 있으며 뉴스레터에도 AVR 관련 뉴스를 포함할 수 있습니다.

나는 또한 얼마 전에 O-AVR 레이블을 만들었으므로 AVR 관련 문제에도 Rust 문제 추적기를 자유롭게 사용하십시오. 그 외에도 대부분의 Rust 팀이 있는 곳이기 때문에 Rust-lang Zulip에서 조정하고 싶을 수도 있습니다. 우리는 또한 특정 Rust 대상(예: Windows 또는 Arm)에 초점을 맞춘 "대상 그룹"을 늘리는 과정에 있으며 AVR도 이에 적합할 수 있습니다. 이에 대해서는 Zulip에 문의하십시오.

업데이트.

libcore 가 스톡 rust-lang/master 브랜치에서 AVR용으로 컴파일되기 전에 두 가지가 남아 있습니다.

1. AVR에서 일련의 "주소 공간 캐스트 무효" 버그를 수정하는 풀 요청이 하나 있습니다. 이는 Rust의 현재 기본값으로 괜찮은 Von-Neumann 대상과 비교하여 Harvard 아키텍처에 대한 함수 포인터가 addrspace(1) 로 태그 지정되어야 하는 방법과 관련이 있습니다. addrspace(0) . Rust-lang/rust#73270 - 현재 코드 검토 중입니다.

~2. blink 예제가 작동하지 못하도록 차단하는 또 다른 버그가 있습니다 - avr-rust/rust#92. 아직 업데이트되지 않은 패치가 있어 이를 수정할 수 있습니다 - https://reviews.llvm.org/D68524. 이것은 업스트림된 다음 유닛 및 통합 테스트를 통과하면

이 두 가지 작업이 완료되면 업스트림된 Rust AVR 대상은 현재 avr-rust/rust 포크와 동일한 수준으로 AVR 코드를 컴파일할 수 있으며 blink 예제 업데이트 프로세스를 시작할 수 있습니다. , arduino 크레이트, 문서, 가이드, 업스트림 분기용. 그런 다음 업스트림 분기를 실험적으로 사용할 준비가 되어 있어야 합니다.

또 하나의 TODO:

1. ~업스트림 Rust의 새로운 인라인 어셈블리 구문을 위한 AVR 배관 추가~
   
   
   
   • ~새로운 인라인 어셈블리 구문이 지원되면 Arduino 크레이트를 업데이트하여 이를 사용해야 합니다.
     
     Arduino 크레이트가 업데이트되면 깜박임 크레이트를 새 버전으로 업데이트하십시오.~ 야간에 여전히 존재하므로 지금은 llvm_asm! 를 통해 이전 매크로를 사용할 수 있습니다.
   
   
2. LLVM 마스터에서 업스트림 Rust LLVM 포크(편집: PR: https://github.com/rust-lang/llvm-project/pull/66)까지 AVR 수정 패치(대부분 Ayke)를 선택합니다.

다음은 모든 것이 포함된 분기입니다. https://github.com/dylanmckay/rust/commits/dylan/avr-workable-upstream-candidate. 이 분기는 libcore를 컴파일하기에 충분합니다.

업스트림 rust-lang/master 에서 빌드되지만 아직 업스트림되지 않은 LLVM 패치 D68524 , 아직 병합되지 않은 Rust PR rust-lang/rust#73270, 업스트림 LLVM에서 자동으로 체리 선택되는 46개의 AVR 관련 커밋도 포함합니다. 스크립트(LLVM 분기: https://github.com/dylanmckay/llvm-project/commits/dylan/avr-workable-upstream-candidate). 46개 모두가 필요한 것은 아니며 최종 목록은 더 작아질 것입니다.

업데이트 : 모든 업스트림 LLVM 수정 사항을 포함하는 풀 요청을 열었습니다.

다음은 LED 깜박임 프로그램을 컴파일하고 성공적으로 실행하기 전에 남은 작업의 전체 목록입니다.

남은 일

• [x] Land Rust PR rust-lang/rust#73270 . 이 풀 요청은 AVR에서 일련의 "주소 공간 캐스트 무효" 버그를 수정하며, 이는 Rust의 현재 기본값인 addrspace(0)에 문제가 없는 Von-Neumann 대상과 비교하여 Harvard 아키텍처에 대한 함수 포인터가 어떻게 addrspace(1)로 태그 지정되어야 하는지에 관한 것입니다. . 현재 코드 검토 중입니다.
• [x] Land Rust LLVM 홍보 https://github.com/rust-lang/llvm-project/pull/66 . 이것은 업스트림 LLVM에서 Rust의 LLVM 포크로 필요한 모든 AVR 수정 사항을 가져옵니다. 결국 ~17~16개의 LLVM 수정 사항을 선별해야 했습니다.
• [x] LLVM 하위 모듈의 버전을 업데이트하는 Land Rust PR rust-lang/rust#73658 . Rust 컴파일러 문서 에는 이를 수행하기 위한 지침이 있습니다. 현재 코드 검토 중 입니다.
• [x] Land Rust PR ~rust-lang/rust#74625~ rust-lang/rust#74631 . 79a42e37084d0에서 Rust는 --eh-frame-hdr 인수를 링커에 무조건 전달하기 시작했습니다. AVR-GCC 링커는 이 플래그를 지원하지 않으므로 기존 Windows 제외와 유사하게 AVR에 대해 전달하지 않도록 특별한 경우가 추가되었습니다. 솔라리스, UEFI.

도구를 Cargo에 직접 추가하는 것이 더 나을 수 있습니다(이에 대한 추적 문제가 있음).

나는 이것이 올바른 문제라고 가정하고 있습니다: rust-lang/cargo#4959.

cargo build -Z build-std=core 는 내 AVR 예제 사례에서 잘 작동했습니다.

@shepmaster 어쨌든 저와 가까워지는 것 같습니다, 감사합니다! 지금은 비트캐스트 항목에 갇힌 것 같으므로 병합될 때까지 기다릴 것입니다(PR을 작성하는 데 필요한 파일과 내가 하고 있는 IDK를 작성하는 데 필요한 파일이 누락된 것으로 보이므로).

-Z build-std=core 을 사용하는 과정에서 target triple을 제공해야 했기 때문에 rustc +master --print target-list | grep avr 를 실행하고 avr-unknown-unknown 찾았습니다. 그러나 보관된 문제 avr-llvm/llvm#35는 트리플이 실제로 avr-atmel-none (어쨌든 나에게 더 이해가 됨)여야 하는 것처럼 들리게 만드는 것 같습니다. 여기에서 업데이트해야 할 사항이 있습니까, 아니면 제가 놓치고 있는 것이 있습니까?

avr-unknown-unknown 맞습니다.

열린 질문

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

나는 이것이 사용자 측면에서 너무 중요하다고 생각하지 않습니다. 이것은 ddg 및/또는 이번 주 러스트를 통해 충분히 쉽게 찾을 수 있었습니다.
무엇이든 개발자를 쉽게 만듭니다.

열린 질문

* Should GitHub issues on the avr-rust fork be moved to the upstream Rust repository?
  ** Regardless, new issues should be raised on the upstream repository - the old issue tracker will need to be wound down.

* Where should the instructions for compiling Rust with AVR live?

나는 이것이 사용자 측면에서 너무 중요하다고 생각하지 않습니다. 이것은 ddg 및/또는 이번 주 러스트를 통해 충분히 쉽게 찾을 수 있었습니다.
무엇이든 개발자를 쉽게 만듭니다.

Rust를 AVR로 컴파일하는 방법은 https://docs.rust-embedded.org/에 있어야 한다고 생각합니다.

알겠습니다. 업데이트 시간입니다.

AVR에 필요한 모든 패치 는 오늘의 nighty rustc 1.47.0-nightly (0820e54a8 2020-07-23) 현재 Rust nightly 컴파일러에 존재합니다 . Rust 야간 컴파일러는 수정 없이 이제 LED 깜박임 예제를 성공적으로 컴파일하고 AVR ELF 파일을 생성할 수 있습니다.

• https://avr-rust.com/ 에서 생성된 새로운 중앙 집중식 프로젝트 랜딩 페이지
• 새 책 - AVR-Rust 가이드북 이 만들어졌으며 book.avr-rust.com의 GitHub 페이지에서 호스팅됩니다.
• avr-rust/rust 포크 저장소는 더 이상 사용되지 않습니다. 영구적으로 잠겨 닫히기 전에 마이그레이션해야 하는 기존 문제가 있으므로 리포지토리가 아직 보관되지 않았습니다.
• Xargo는 더 이상 필요하지 않습니다 - 업스트림 Rust의 -Z build-std 플래그가 AVR에서 Xargo의 필요성을 대체합니다. 화물 포크는 더 이상 필요하지 않습니다. 상류 화물이 필요합니다.

Rust nightly 컴파일러는 이제 AVR을 지원하는 Rust의 권장 채널로 간주될 수 있습니다.

나는 지금 이 문제를 닫고 있습니다 - 우리가 해냈습니다!

버그 보고 단계는 AVR 가이드북 에서 찾을 수 있습니다.

AVR 가이드북 과 https://github.com/avr-rust/blink 의 깜박임 예제는 대상 사용을 시작하는 데 가장 좋은 리소스입니다.

이 업스트림 노력을 통해 프로젝트를 논의하고 지원한 모든 사람에게 깊이 감사드립니다. 매우 감사합니다.

지느러미

와우 와우 와우.

이 일에 기여해 주신 모든 분들께 감사드립니다. 저는 지금까지 이 날을 고대해 왔습니다!

녹을 avr로 이식하기 전의 Dylan McKay

그리고 후에

모든 노력에 감사드립니다! :-) 푹 쉬세요!