Design: Arithmétique avec retenue

Il me semble que pour l'option 3, il existe des optimisations plausibles qui rendraient cela pratique. Supposons que {i32,i64}.addc prend trois entrées, op2 en haut, op1 en dessous, report en bas et produit deux sorties, résultat en haut et report en dessous. Pour les besoins de l'argument, supposons que le report est toujours du même type que les autres opérandes. Définissez addc uniquement pour utiliser le bit bas du report et pour que le report restant après l'opération soit zéro ou un. Les choses sont maintenant raisonnablement configurées pour un ajout de plusieurs mots, par exemple. Dans une boucle correctement déroulée, un compilateur JIT/Wasm devrait vraiment être capable de voir que c'est le report qui est propagé et de générer du bon code. (Et si la boucle n'est pas déroulée, la surcharge de la boucle diluera de toute façon l'extraction/l'insertion de retenue.) Je pense que le pire des cas de code sans branche pour l'extraction de retenue devrait être mov rd, 0; adc rd, 0 ; pour l'insertion, quelque chose comme and rc, 1; add rc, ~0 où rc est un registre qui contient une valeur à traiter comme un report.

Sur ARM, la consommation d'un report est distincte de la production d'un report : ADC consomme, ADC.S consomme et produit, ADD.S ne fait que produire. Voudrions-nous toutes ces variantes ? Et qu'en est-il du débordement ?

(Il pourrait y avoir une quatrième option, où nous ajoutons une opération d'opération et de branchement sur condition qui produit à la fois un résultat et se branche sur une étiquette ou non, par exemple, i32.addc op1 op2 carry L se brancherait sur L sur l'ensemble de report et tomber sur le carry clear, et de toute façon laisser un résultat sur la pile, mais cela semble plus difficile à utiliser en général que les trois options que vous avez suggérées.)

Y a-t-il quelqu'un prêt à défendre cette proposition? Nous aurions besoin d'une sémantique proposée, d'un encodage binaire, et j'aimerais au moins au moins des cas d'utilisation et une implémentation avec des chiffres de performance pour ces cas d'utilisation (comparez le MVP WebAssembly actuel, avec cet ajout proposé, et le code natif).

En principe, je serais prêt à défendre cela.
Cependant, des changements personnels signifient que j'ai des ressources limitées pour au moins les prochains mois.
———
Franck McCabe
Architecte logiciel sénior
Téléphone : 650-740 6673 | Courriel : [email protected] [email protected]
Logique de démarrage | 450, avenue Lambert, Palo Alto, Californie 94306 | instartlogic.com http://instartlogic.com/

Le 11 mai 2017 à 10h14, JF Bastien [email protected] a écrit :

Y a-t-il quelqu'un prêt à défendre cette proposition? Nous aurions besoin d'une sémantique proposée, d'un encodage binaire, et j'aimerais au moins au moins des cas d'utilisation et une implémentation avec des chiffres de performance pour ces cas d'utilisation (comparez le MVP WebAssembly actuel, avec cet ajout proposé, et le code natif).

—
Vous recevez ceci parce que vous êtes l'auteur du fil.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/WebAssembly/design/issues/1021#issuecomment-300856161 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/ADfCzd9le4ufXm6DSsArpfXCYsGdV7UIks5r40H5gaJpZM4MrKma .

J'aurai probablement du temps à consacrer à cela, mais pas beaucoup avant juin environ, puis à l'automne. IMO, cette fonctionnalité est assez importante, et je pense que l'indicateur de débordement est aussi important que l'indicateur de report, bien qu'avec différents cas d'utilisation (transition fixnum -> bignum des langages dynamiques).

J'en ai discuté avec des gens de Mozilla aujourd'hui. En résumé:

• Nous voulons probablement des instructions dédiées ici parce que l'émulation du comportement sera lente et nous ne voulons généralement pas faire de correspondance de modèle magique pour reconnaître l'émulation et la transformer en code machine efficace dans les coulisses
• Nous nous soucions du report/de l'emprunt et du débordement, bien sûr ; autres drapeaux à déterminer
• Nous nous soucions d'ajouter et de soustraire à coup sûr; multiplier, diviser, faire pivoter (la rotation à travers le report est courante mais est-ce utile pour Wasm ?) À déterminer
• Le cas courant est que nous ne nous soucions que d'un drapeau à la fois et il est probablement suffisant pour couvrir ce cas, pas une situation générale de "capture des drapeaux A, B et C"
• Pour le report, une instruction qui consomme toujours un report entrant et produit toujours un report est suffisante ; les variantes qui consomment mais ne produisent pas ou vice versa ne sont pas nécessaires, et ne pas les avoir n'affectera probablement pas la sortie d'un bon compilateur
• Nous voulons motiver ce travail avec des données provenant de bonnes bibliothèques MP existantes (telles que Gnu MP); cela peut être des faits (la bibliothèque X a/n'a pas de sous-routines assembleur ou utilise des éléments intrinsèques pour utiliser les drapeaux ; elle utilise les instructions A et B) ou des données de performances (la bibliothèque Y peut utiliser des sous-routines assembleur ou émuler en C ; la différence de performances est de N % ) ou cas d'utilisation (arithmétique bignum générale, crypto, tout ce qui vous vient à l'esprit)
• Nous voudrons peut-être attendre avant de proposer des instructions spécifiques jusqu'à ce que nous commencions à discuter des instructions produisant des valeurs multiples en général, par exemple, des retours à valeurs multiples

Y a-t-il eu des progrès sur cette question? Le transport et l'emprunt sont nécessaires pour mettre en œuvre efficacement la cryptographie moderne (par exemple SIDH). L'addition de grands nombres sans ADDC est plusieurs fois plus lente qu'avec. Il en va de même pour la soustraction et la multiplication.

Je pense que nous attendons au moins que la multi-valeur soit terminée afin que nous puissions facilement exprimer une opération avec plus d'un résultat. La multi-valeur est "presque là".