Design: 캐리가 있는 산술

옵션 3의 경우 이를 실용적으로 만드는 그럴듯한 최적화가 있는 것 같습니다. {i32,i64}.addc가 3개의 입력(상단에 op2, 하단에 op1, 하단에 carry)을 취하여 두 개의 출력을 생성한다고 가정합니다. 결과는 상단에, 그리고 하단에는 carry가 발생합니다. 인수를 위해 캐리가 항상 다른 피연산자와 같은 유형이라고 가정합니다. 캐리의 하위 비트를 사용하고 연산 후 남은 캐리가 0 또는 1이 되도록 addc를 정의하십시오. 이제 여러 단어를 추가할 수 있는 상황이 합리적으로 설정되었습니다. 적절하게 펼쳐진 루프에서 JIT/Wasm 컴파일러는 실제로 전파되고 있는 것이 캐리임을 확인하고 좋은 코드를 생성할 수 있어야 합니다. (그리고 루프가 풀리지 않으면 루프 오버헤드가 어쨌든 캐리 추출/삽입을 희석시킬 것입니다.) 캐리 추출을 위한 최악의 경우 분기가 없는 코드는 mov rd, 0; adc rd, 0 여야 한다고 생각합니다. 삽입의 경우 and rc, 1; add rc, ~0 와 같은 것입니다. 여기서 rc는 캐리로 처리될 값을 포함하는 레지스터입니다.

ARM에서 캐리를 소비하는 것은 캐리를 생성하는 것과 별개입니다. ADC는 소비하고 ADC.S는 소비하고 생산하며 ADD.S는 생산만 합니다. 이 모든 변형을 원할까요? 그리고 오버플로는 어떻습니까?

(예를 들어 i32.addc op1 op2 carry L 는 캐리 세트에서 L로 분기할 것입니다. 캐리 클리어 시 넘어지고 어느 쪽이든 스택에 결과를 남기지만 일반적으로 제안한 세 가지 옵션보다 사용하기가 더 어려워 보입니다.)

이 제안을 지지할 사람이 있습니까? 우리는 제안된 의미 체계, 이진 인코딩이 필요하고 최소한 최소한의 사용 사례와 이러한 사용 사례에 대한 성능 수치가 있는 구현을 원합니다(현재 MVP WebAssembly와 이 제안된 추가 및 기본 코드를 비교).

원칙적으로 나는 이것을 옹호할 용의가 있습니다.
그러나 개인적인 변화로 인해 최소한 앞으로 몇 달 동안 리소스가 제한됩니다.
———
프랭크 맥케이브
수석 소프트웨어 설계자
전화: 650-740 6673 | 이메일: [email protected] [email protected]
논리 시작 | 450 Lambert Ave, 팔로 알토, CA 94306 | instartlogic.com http://instartlogic.com/

2017년 5월 11일 오전 10시 14분에 JF Bastien [email protected] 에서 다음과 같이 썼습니다.

이 제안을 지지할 사람이 있습니까? 우리는 제안된 의미 체계, 이진 인코딩이 필요하고 최소한 최소한의 사용 사례와 이러한 사용 사례에 대한 성능 수치가 있는 구현을 원합니다(현재 MVP WebAssembly와 이 제안된 추가 및 기본 코드를 비교).

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/WebAssembly/design/issues/1021#issuecomment-300856161 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/ADfCzd9le4ufXm6DSsArpfXCYsGdV75UIks5 스레드를 음소거합니다.

6월 정도까지는 그리 많지는 않지만 이 일에 전념할 시간이 있을 것입니다. IMO 이 기능은 상당히 중요하며 다른 사용 사례(동적 언어의 fixnum -> bignum 전환)에서 오버플로 플래그가 carry 플래그만큼 중요하다고 생각합니다.

오늘 일부 Mozilla 사용자와 이에 대해 논의했습니다. 요약하자면:

• 동작을 에뮬레이션하는 것은 느리고 일반적으로 에뮬레이션을 인식하고 배후에서 효율적인 기계 코드로 전환하기 위해 마법의 패턴 일치를 수행하고 싶지 않기 때문에 여기에서 전용 지침을 원할 것입니다.
• 우리는 확실히 carry/borrow 및 overflow에 관심이 있습니다. 기타 플래그 미정
• 우리는 확실히 더하기와 빼기에 신경을 쓰고 있습니다. 곱하기, 나누기, 회전(rotate-through-carry가 일반적이지만 Wasm에 유용합니까?) TBD
• 일반적인 경우는 한 번에 하나의 플래그에만 관심을 두고 있으며 일반적인 "플래그 A, B 및 C 캡처" 상황이 아니라 해당 경우를 다루는 것이 적절할 수 있다는 것입니다.
• 캐리의 경우 항상 캐리인을 사용하고 항상 캐리아웃을 생성하는 명령이면 충분합니다. 소비하지만 생성하지 않는 변형은 필요하지 않으며, 이러한 변형이 없으면 좋은 컴파일러의 출력에 영향을 미치지 않을 것입니다.
• 우리는 기존의 좋은 MP 라이브러리(Gnu MP와 같은)의 데이터로 이 작업에 동기를 부여하고자 합니다. 이것은 사실(라이브러리 X에는 어셈블러 서브루틴이 있거나 없거나 플래그를 사용하기 위해 내장 함수를 사용합니다. 명령어 A와 B를 사용함) 또는 성능 데이터(라이브러리 Y가 어셈블러 서브루틴을 사용하거나 C에서 에뮬레이트할 수 있음, 성능 차이는 N%)일 수 있습니다. ) 또는 사용 사례(일반 빅넘 산술, 암호화, 기타 생각나는 모든 것)
• 일반적으로 다중 값 반환과 같은 다중 값 생성 명령에 대해 논의하기 시작할 때까지 특정 명령을 제안하면서 기다릴 수 있습니다.

이 문제에 대한 진전이 있었습니까? 현대 암호화(예: SIDH)를 효율적으로 구현하려면 캐리 및 빌림이 필요합니다. ADDC 없이 큰 수를 더하면 여러 요인이 있을 때보다 느립니다. 뺄셈과 곱셈도 마찬가지입니다.

적어도 하나 이상의 결과가 있는 연산을 쉽게 표현할 수 있도록 다중 값이 완료되기를 기다리고 있다고 생각합니다. 다중 값은 "거의 있습니다".