Design: Aritmatika dengan carry

Menurut saya untuk opsi 3 ada pengoptimalan yang masuk akal yang akan membuat ini praktis. Misalkan {i32,i64}.addc mengambil tiga input, op2 di atas, op1 di bawah, carry di bawah dan menghasilkan dua output, hasil di atas dan carry di bawahnya. Demi argumen, asumsikan carry selalu bertipe sama dengan operan lainnya. Tentukan addc hanya untuk menggunakan bit rendah dari carry dan untuk carry yang tersisa setelah operasi menjadi nol atau satu. Hal-hal sekarang cukup diatur untuk menambahkan multi-kata, katakanlah. Dalam unrolled loop yang sesuai, kompiler JIT/Wasm benar-benar harus dapat melihat bahwa itu adalah carry yang disebarkan, dan menghasilkan kode yang baik. (Dan jika loop tidak dibuka maka loop overhead akan mencairkan ekstraksi/penyisipan carry.) Saya pikir kasus terburuk kode bebas cabang untuk ekstraksi carry seharusnya mov rd, 0; adc rd, 0 ; untuk penyisipan, sesuatu seperti and rc, 1; add rc, ~0 di mana rc adalah register yang berisi nilai untuk diperlakukan sebagai carry.

Di ARM, mengkonsumsi carry terpisah dari memproduksi carry: ADC mengkonsumsi, ADC.S mengkonsumsi dan memproduksi, ADD.S hanya memproduksi. Apakah kita menginginkan semua varian ini? Dan bagaimana dengan overflow?

(Mungkin ada opsi keempat, di mana kita menambahkan operasi operasi-dan-cabang-pada-kondisi yang keduanya menghasilkan hasil dan cabang ke label atau tidak, misalnya, i32.addc op1 op2 carry L akan bercabang ke L pada carry set dan lolos dari carry clear, dan bagaimanapun meninggalkan hasil di tumpukan, tetapi tampaknya lebih sulit untuk digunakan secara umum daripada tiga opsi yang Anda sarankan.)

Apakah ada yang mau memperjuangkan proposal ini? Kami membutuhkan semantik yang diusulkan, pengkodean biner, dan saya ingin setidaknya setidaknya kasus penggunaan dan implementasi dengan nomor kinerja untuk kasus penggunaan ini (bandingkan MVP WebAssembly saat ini, dengan penambahan yang diusulkan ini, dan kode asli).

Pada prinsipnya, saya akan bersedia untuk memperjuangkan ini.
Namun, perubahan pribadi berarti saya memiliki sumber daya yang terbatas setidaknya untuk beberapa bulan ke depan.
———
Frank McCabe
Arsitek Perangkat Lunak Senior
Telepon: 650-740 6673 | Email: [email protected] [email protected]
Mulai Logika | 450 Lambert Ave, Palo Alto, CA 94306 | instartlogic.com http://instartlogic.com/

Pada 11 Mei 2017, pukul 10:14, JF Bastien [email protected] menulis:

Apakah ada yang mau memperjuangkan proposal ini? Kami membutuhkan semantik yang diusulkan, pengkodean biner, dan saya ingin setidaknya setidaknya kasus penggunaan dan implementasi dengan nomor kinerja untuk kasus penggunaan ini (bandingkan MVP WebAssembly saat ini, dengan penambahan yang diusulkan ini, dan kode asli).

—
Anda menerima ini karena Anda yang menulis utas.
Balas email ini secara langsung, lihat di GitHub https://github.com/WebAssembly/design/issues/1021#issuecomment-300856161 , atau nonaktifkan utasnya https://github.com/notifications/unsubscribe-auth/ADfCzd9le4ufXm6DSsArpfXCYsGdV7UIks5rZ .

Saya mungkin akan punya waktu untuk mencurahkan ini meskipun tidak terlalu banyak sampai Juni atau lebih, dan kemudian ke musim gugur. IMO fungsi ini cukup penting, dan saya pikir flag overflow sama pentingnya dengan flag carry meskipun dengan kasus penggunaan yang berbeda (fixnum bahasa dinamis -> transisi bignum).

Membahas ini dengan beberapa orang Mozilla hari ini. Singkatnya:

• Kami mungkin menginginkan instruksi khusus di sini karena meniru perilaku akan menjadi lambat dan kami biasanya tidak ingin melakukan pencocokan pola ajaib untuk mengenali emulasi dan mengubahnya menjadi kode mesin yang efisien di belakang layar
• Kami peduli dengan carry/borrow and overflow, pastinya; bendera lainnya TBD
• Kami peduli tentang menambah dan mengurangi pasti; mengalikan, membagi, memutar (memutar-melalui-membawa adalah umum tetapi apakah itu berguna untuk Wasm?) TBD
• Kasus umum adalah bahwa kita hanya peduli pada satu bendera pada satu waktu dan mungkin cukup untuk menutupi kasus itu, bukan situasi umum "tangkap bendera A, B, dan C"
• Untuk carry, instruksi yang selalu mengkonsumsi carry-in dan selalu menghasilkan carry-out sudah cukup; varian yang mengkonsumsi tetapi tidak menghasilkan atau sebaliknya tidak diperlukan, dan tidak memilikinya mungkin tidak akan memengaruhi output dari kompiler yang baik
• Kami ingin memotivasi pekerjaan ini dengan data dari perpustakaan MP baik yang ada (seperti Gnu MP); ini bisa berupa fakta (perpustakaan X tidak/tidak memiliki subrutin assembler atau menggunakan intrinsik untuk menggunakan flag; ia menggunakan instruksi A dan B) atau data kinerja (perpustakaan Y dapat menggunakan subrutin assembler atau meniru dalam C; perbedaan perf adalah N% ) atau kasus penggunaan (aritmatika bignum umum, kripto, apa pun yang terlintas dalam pikiran)
• Kita mungkin ingin menunggu dengan mengusulkan instruksi khusus sampai kita mulai membahas instruksi produksi nilai ganda secara umum, misalnya, pengembalian nilai ganda

Apakah ada kemajuan dalam masalah ini? Membawa dan meminjam diperlukan untuk mengimplementasikan kriptografi modern (misalnya SIDH) secara efisien. Penambahan jumlah besar tanpa ADDC adalah beberapa faktor lebih lambat dibandingkan dengan. Hal yang sama berlaku untuk pengurangan dan perkalian.

Saya pikir kami setidaknya menunggu multi-nilai selesai sehingga kami dapat dengan mudah mengekspresikan operasi dengan lebih dari satu hasil. Multi-nilai adalah "hampir sampai".