Design: quand devrions-nous avoir besoin d'un code de colle ?

Créé le 9 avr. 2018  ·  4Commentaires  ·  Source: WebAssembly/design

Je rencontre quelques cas.

un, nous avons besoin d'un code de colle :

int addThree(uint8_t *buf, int len) {
  uint8_t *item;
  uint8_t *end = buf + len;

  for (item = buf; item<end; item++) {
    *item += 3;
  }

  return 0;
}

mais, de manière simple, nous avons seulement besoin d'utiliser le fichier .wasm

int adder (int a, int b) {
    return a + b;
}

alors, que fait le code de la colle? Je n'ai pas trouvé de doc.

Commentaire le plus utile

Le code de collage décrit dans le commentaire ci-dessus est le chargeur JavaScript généré par Emscripten. Il fait exactement ce que dit le commentaire : convertit entre les représentations de données JS et C++ (par exemple des chaînes) et entre différentes représentations d'objets (c'est-à-dire en créant des objets proxy JS pour les objets C++). Il crée également les tableaux typés nécessaires.

Comme vous l'avez remarqué, vous pouvez vous passer du chargeur Emscripten pour des cas simples comme les deux fonctions que vous avez utilisées comme exemples. Aucun d'eux ne nécessite de code de collage complexe : chacun a simplement besoin d'un fichier JS pour charger le fichier Wasm (et dans le deuxième exemple, le fichier wasm d'addThree aura également besoin du Uint8Array pour être créé).

Enfin, l'allocation de mémoire est gérée par le code Wasm, qui devrait inclure une copie de malloc de musl (bien qu'Emscripten inclue toujours son malloc en fait, plutôt que d'utiliser celui de musl). Les fuites de mémoire sont évitées de manière standard simplement en libérant de la mémoire dans votre code C/C++ une fois que vous en avez terminé, il n'y a rien de spécial requis par Wasm ici.

En fin de compte, vous n'avez besoin que du code de collage que vous utiliserez réellement, en fonction des appels transfrontaliers effectués par votre code (de JS vers C++ et de C++ vers JS).

Ce problème pourrait être clos, il s'agit d'une question sur Emscripten plutôt que d'un bug dans la conception WebAssembly elle-même.

Tous les 4 commentaires

Quel code de colle ? Vous semblez avoir copié ici deux fonctions ( addThree() et adder() ) de certains tutoriels Wasm peut-être ? Ils semblent être simplement des exemples de fonctions qui ne font pas grand-chose et servent simplement à illustrer un simple didacticiel Wasm. Aucune de ces fonctions n'a de signature complexe et doit pouvoir être appelée sans aucun code de collage.

Mais, ce n'est pas mon propos. À partir de certains documents, il explique comme ceci :

À long terme, wasm avec des objets typés et GC pourrait aider. C'est ce que l'on veut dire ici ?
Sinon, je ne sais pas comment ce code de colle peut être supprimé à court ou à moyen terme. Il faut beaucoup de travail pour former un shell autour de choses C/C++ qui les font ressembler à une chose JS. Par exemple, le code de collage doit contenir des méthodes pour convertir une chaîne C en une chaîne JS, et vice versa. Au niveau C++, la prise en charge de l'extension d'une classe C++ dans JS et l'implémentation de méthodes virtuelles dans JS demande un peu de piratage. Et en général, beaucoup de colle sera nécessaire pour accéder aux API Web de wasm à JS.

et d'autres:

Emscripten nécessite une grande variété de code JavaScript "colle" pour gérer l'allocation de mémoire, les fuites de mémoire et une foule d'autres problèmes, qui sont déjà inclus dans le modèle fourni. C'est plus facile à utiliser que d'avoir à tout écrire vous-même

Lorsque je rencontre du code simplement C/C++, je pourrais facilement utiliser wasm en le compilant, et export.xxxFn() .

int adder (int a, int b) {
    return a + b;
}

et lorsque j'utilise du code qui utilise Buffer, je préfère utiliser du code glue.

# C/C++
int addThree(uint8_t *buf, int len) {
  uint8_t *item;
  uint8_t *end = buf + len;

  for (item = buf; item<end; item++) {
    *item += 3;
  }

  return 0;
}

# deal with buffer in JS
...
let dataHeap = new Uint8Array(Module.HEAPU8.buffer, dataPtr, nDataBytes);
dataHeap.set(new Uint8Array(buffer_pcm.buffer));
...

donc, je pourrais conclure que lorsque je transfère Buffer vers WASM, j'ai besoin de code de colle pour gérer l'allocation de mémoire, les fuites de mémoire et une foule d'autres problèmes ?

Le code de collage décrit dans le commentaire ci-dessus est le chargeur JavaScript généré par Emscripten. Il fait exactement ce que dit le commentaire : convertit entre les représentations de données JS et C++ (par exemple des chaînes) et entre différentes représentations d'objets (c'est-à-dire en créant des objets proxy JS pour les objets C++). Il crée également les tableaux typés nécessaires.

Comme vous l'avez remarqué, vous pouvez vous passer du chargeur Emscripten pour des cas simples comme les deux fonctions que vous avez utilisées comme exemples. Aucun d'eux ne nécessite de code de collage complexe : chacun a simplement besoin d'un fichier JS pour charger le fichier Wasm (et dans le deuxième exemple, le fichier wasm d'addThree aura également besoin du Uint8Array pour être créé).

Enfin, l'allocation de mémoire est gérée par le code Wasm, qui devrait inclure une copie de malloc de musl (bien qu'Emscripten inclue toujours son malloc en fait, plutôt que d'utiliser celui de musl). Les fuites de mémoire sont évitées de manière standard simplement en libérant de la mémoire dans votre code C/C++ une fois que vous en avez terminé, il n'y a rien de spécial requis par Wasm ici.

En fin de compte, vous n'avez besoin que du code de collage que vous utiliserez réellement, en fonction des appels transfrontaliers effectués par votre code (de JS vers C++ et de C++ vers JS).

Ce problème pourrait être clos, il s'agit d'une question sur Emscripten plutôt que d'un bug dans la conception WebAssembly elle-même.

Merci beaucoup

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

void4 picture void4  ·  5Commentaires

chicoxyzzy picture chicoxyzzy  ·  5Commentaires

beriberikix picture beriberikix  ·  7Commentaires

mfateev picture mfateev  ·  5Commentaires

aaabbbcccddd00001111 picture aaabbbcccddd00001111  ·  3Commentaires