Design: Données initiales et endiannes

Créé le 3 sept. 2016 · 6Commentaires · Source: WebAssembly/design

La spécification ne dit rien sur l'ordre des octets utilisé par i32.load . Les programmes du monde réel contiennent une section de données pour fournir des tables virtuelles, des données statiques, etc. Ces éléments nécessitent généralement des types de valeur différents. Cependant, WebAssembly est limité aux séquences d'octets dans sa section data . Avec des octets, on ne peut pas émuler int32, car ils ne connaissent rien aux endiannes.

Ce serait bien si WebAssebmly avait quelque chose de similaire aux structures et aux initialiseurs de structure similaires à LLVM. Cela résout non seulement le problème des endiannes des données statiques, mais donne également la possibilité de diminuer les données binaires, car les entiers dans la section de données consommeront probablement moins d'octets dans la représentation LEB128, alors qu'ils consomment toujours 4 octets lorsqu'ils sont codés dans la section de données.

Les solutions de contournement actuelles sont :

n'utilisez pas la section de données, utilisez plutôt la fonction d'initialisation large
inventer son propre format, inclure le décodeur dans le binaire WebAssembly, l'exécuter à partir de la fonction start

Source

konsoletyper

Commentaire le plus utile

Il y a des avantages significatifs à ne pas avoir à gérer plusieurs endianités dans l'écosystème, et la probabilité qu'une architecture CPU qui n'ait pas au moins une prise en charge efficace des accès little-endian devienne populaire dans un avenir prévisible est considérée comme très faible.

sunfishcode le 5 sept. 2016

👍4

Tous les 6 commentaires

WebAssembly est petit-boutiste. Il semble qu'AstSemantics.md ne le mentionne pas ; J'ai maintenant déposé https://github.com/WebAssembly/design/pull/787 pour corriger cela.

Il est mentionné ici et ici et testé ici .

L'idée d'avoir des données codées LEB128 dans la section de données est intéressante. Cela peut être fait de différentes manières, soit avec un nouveau type d'initialiseur de données, soit avec une compression de couche 1 . La compression de couche 2 peut également être utile pour les segments de données volumineux en général.

sunfishcode le 3 sept. 2016

Je vois Merci. N'est-ce pas une exigence trop forte ? Je ne connais aucun processeur qui utilise big-endian, mais si, pour une raison quelconque, un processeur apparaît et devient largement utilisé, WebAssembly s'exécutera sur ce processeur avec une certaine surcharge.

konsoletyper le 3 sept. 2016

sunfishcode le 5 sept. 2016

👍4

Le sam. 3 sept. 2016 à 16:07, Alexey Andreev [email protected]
a écrit:

Je vois Merci. N'est-ce pas une exigence trop forte ? Il n'y a pas de CPU I
savoir qui utilise big-endian, mais si pour une raison quelconque apparaît et devient
largement utilisé, WebAssembly s'exécuterait sur ce processeur avec une certaine surcharge.
Les processeurs MIPS et SPARC sont big-endian, bien que SPARC ait eu little-endian
charge/stocke depuis un certain temps maintenant, et MIPS a des variantes de petite envergure.

Nous avons implémenté la prise en charge big-endian dans la V8 via l'échange explicite d'endianness
code mais n'ont pas encore mesuré les frais généraux avec soin.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WebAssembly/design/issues/786#issuecomment-244548450 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALnq1EEkfh88rAXYByuL9uNcjbsjVnFbks5qmX8agaJpZM4J0Snh
.

titzer le 5 sept. 2016

Ce serait bien si WebAssebmly avait quelque chose de similaire aux structures et aux initialiseurs de structure similaires à LLVM.

C'est déjà faisable dans WebAssembly exactement de la même manière que dans C et C++ : avant que main() ne soit appelé, la fonction _start peut appeler les fonctions .init_array. Je pense qu'il n'y a rien à faire ici.

D'accord avec @sunfishcode / @titzer sur l'endianness.