Commits

Calascibetta Romain  committed db7d17f

Add new section in README

  • Participants
  • Parent commits 238c109

Comments (0)

Files changed (1)

     problèmes mentionnés précédemment, est qu'il propose un moyen d'éviter un
     certain nombre d'erreurs grâce au système de types d'OCaml.
 
-    L'idée 
+    Le projet s'inspire en masse au projet TyXML. On s'articule donc autour de
+    la puissance du système de type d'OCaml (typage, variant polymorphes, GADT)
+    pour pouvoir générer du code LLVM-IR dont une analyse statique aura déjà
+    était faite.
+
+Le Projet:
+    LLVM-IR s'articule autour de 2 modules. L'un correspond à proprement parler 
+    du code LLVM-IR tandis que l'autre offre une abstraction aux données associées
+    à leurs types. En combinant les deux, on parvient à déceler des erreurs de
+    types basiques.
+
+    LLVM:
+
+    Le module LLVM s'organise sur 3 niveau. Une implémentation semblable en Coq
+    valide cette prise de position. Il s'agit, au premier niveau, de pouvoir
+    définir des variables globales ou des fonctions mais aussi de pouvoir
+    déclarer des fonctions externes. Le deuxième niveau correspond à la définition
+    des labels et de l'instruction `ret` qui est très spécifique. Enfin, le
+    troisième niveau correspond au code proprement parlé à l'aide d'un arbre
+    d'instruction qui n'est pas uniforme dans le typage.
+
+    C'est ensuite en utilisant la structure des listes qui permet de compléter le
+    code comme c'est déjà le cas dans TyXML. Ensuite, à l'aide d'un ensemble de
+    fonctions internes au module, nous générons sur la sortie standard du code
+    LLVM-IR.
+
+    Certains points peuvent être notés comme l'utilisation dans certaines
+    situations des variants polymorphes afin d'étayer le système de type sur
+    les différents attributs que peuvent prendre la déclaration de fonction et
+    la définition de variable global notamment. L'idée est d'interdire
+    l'utilisateur de l'API de pouvoir mettre un mauvais linkage sur la
+    déclaration de fonction (ce qui aurait été possible dans le système de sous
+    typage d'OCaml).
+
+    Même si nous avons réussi à faire respecter certaines règles de façon statique
+    dans la génération du code LLVM-IR, il reste tout de même des points qui ne
+    peuvent être vérifier sans un système plus fort que celui d'OCaml. En effet,
+    on peut parler de l'attribut `asign` qui ne peut prendre que des puissances de
+    2 entant que paramètres. Il nous aurait fallut un système de type de dépendant
+    comme celui de Coq pour y parvenir.
+
+    D'autres situations plus difficiles à contextualiser montrent aussi les
+    limites du système de typage de l'OCaml mais même si c'est le cas, il faut
+    aussi accorder une certaines confiance à l'utilisateur.
+
+    LLVM_types:
+
+    /* jpdeplaix */
+
+Le résultat:
+    Même si nous avions certains problèmes lors de l'implémentation de TyLLVM,
+    l'objectif est clairement de pouvoir donner une API plus stable et se
+    rapprochant le plus possible de la philosophie de l'OCaml.
+
+    Ainsi, nous avons essayé de générer comme point de départ un simple code
+    de LLVM-IR qui affiche un « Hello World ! » afin de valider notre point de
+    vu sur la génération d'un code LLVM-IR en OCaml.
+
+    L'approche TyXML peut être critiquable (en prenant en comparaison la
+    sémantique du XML et de LLVM-IR), néanmoins si nous arrivons à des
+    résultats, c'est que ce style d'implémentation est tout à fait possible.
 
 Références:
     [1]: https://llvm.org/viewvc/llvm-project/llvm/trunk/bindings/ocaml/llvm/llvm.mli?view=markup