L'architecture des web Assembly: allons plus en details

Après avoir abordé la notion des webassembli ici, parlons en en présence de son architecture pour mieux la comprendre.

L'architecture des WebAssembly : un peu de détails.

=> JIT (Just in time compilation) vs AOT (Ahead of time compilation)

le code que nous en tant que developpeur écrivons que soit pour du web, mobile ou desktop etc.. doit etre traduit d'une manière ou d'une autre en code binaire (1011010110101) qui en fait est l'unique chose que comprennent les machines, chaque machine cependant à un processeur different les uns des autres, donc en consequence à chaque machine correspond son code binaire, donc en fait comment font donc les compilateur pour convertire le code en langage de programmation en code binaire compatible à tous les processeurs de chaque machine? that a big question.

En image 1, le code c,c++ ou rust est d'abord convertit en un code intermediaire (en anglais on parle de intermediate representation ou IR sur l'image), donc techniquement parlant, le processus de conversion du code en binaire specifique pour une machine est divisé en deux compartiment : le frontend(ici il ne s'agit pas du frontend web mais du frontend vu sous l'angle du processus de compilation donc à ne pas confondre) qui s'occupe de convertir le code c ou c++ en code IR, puis il y aura un backend (toujours à ne pas confondre avec le backend habituel) qui va prendre le code IR et le traduire en code binaire compatible à chaque processeur, generalement, le compilateur utilisé pour faire ce travail final c'est le JIT (Just In Time Compilation).

 

Pour faire simple, le code javascript en image 2, est constament monitoré par le moteur javascript du navigateur, car javascript étant un langage dynamique ou on ne connait pas le type de variable, le moteur doit l'interpreter à tout moment pour detecter par exemple si les variables a ou b sont des entiers ou des chaines de caractère, et ensuite les compilé en JIT en code binaire et il doit faire cette opération à chaque fois que quelque chose change dans le DOM ou cette fonction est appellée ce qui est une opération couteuse en terme de performance pour certaines activités.

Par contre les languages comme le C, C++ par exemple peuvent utiliser une procedure de compilation en amont, qu'on appelle AOT (Ahead of Time compilation), donc le code est completement traduit en un code intermediaire ou bytecode, avant d'etre passer au JIT pour le traduire en bianire, l'avantage ici étant qu'on ne doit pas monitorer le code pour comprendre le type de variable, on obtient dejà un format pret à etre traduit en binaire et c'est plus rapide en terme d'execution. Justement les langages C, C++ et Rust qui sont actuellement les langages supportés par les webassembly, comme le montre l'image 3, sont d'abord convertit en un format binaire qui n'est pas le code machine (wasm) mais un format accepté standardisé et accepté par tous les concepteurs des navigateurs web qui a sa propre structure car le wasm n'est pas un langage de programmation destiné aux developpeurs mais un format binaire interpretable par les navigateurs donc les developpeurs doivent etre capable d'ècrire du code dans un langage et pouvoir à travers une compilation le porter en format wasm, ce fichier wasm qui generalement est charge dans le navigateur à travers javascript, est ensuite compilé en JIT par le moteur javascript du navigateur en code binaire specifique pour le processeur de la machine ou se trouve le navigateur (cela peut etre un PC, un smartphone etc..), donc en faisant l'analogie frontend + backend de notre compilateur on a un peu ce qu'on voit en image 4.

=> Format d'un fichier wasm

un fichier wasm que l'on voit en image 5 contient les parties suivantes:

1. Preamble : contient un nombre magique (0x00 0x61 0x73 0x6D) pour faire une distintion entre les modules des webassembly et ceux de ecamscript 6, ce numero magique est suivit d'un numero de version (0x01 0x00 0x00 0x00) qui indique la version du format wasm utilisé pour créer le fichier wasm.

2. Le preamble est suivit par plusieurs sections qui sont toutes optionelles, et techniquement on peut avoir un module wasm sans section, il en existe deux types de sections, les connues (known) et les sections personalisées (custom), les sections connues on chacun un objectif bien spécifique et doivent etre inserrées une seule fois et dans l'ordre, les sections personalisées par contre permettent d'inserrer des informations pas disponible dans les sections known.

Pour plus d'information sur les specifité du format des wasm bien vouloir se reporter à ce lien : https://webassembly.github.io/spec/core/binary/index.html

Bon Coding

---

---

Share

Comments (0)

Leave A Comment

Your Name:
Comment: