[Kos-dev] Pseudo-compilateur

[kos-dev@enix.org]

salut,

ce WE j'etais chez Julien a Saverne, et nous avons donc pu commencer a
travailler sur le pseudo compilateur. ce pseudo compilateur est charg=E9
de deux taches distinctes (mais liees) :
        1. convertir des fichiers de description d'interface (.ki) en
.h et en code C correspondant
        2. faire quelques remplacements sur des fichiers de code (.k)
et notamment remplacement du pointeur "this", ainsi que des noms de
methodes.

Nous avons commence par reflechir sur le deroulement de la
compilation. Apres moultes reflexions, nous avons decide la chose
suivante :

  Chaque .ki sera compile separement. La compilation d'un .ki ne
  donnait lieu =E0 la g=E9n=E9ration que d'un seul et unique .h. Si le =
.ki
  comporte des inclusions d'autres .ki, ceux ci sont simplement
  recopies sous forme d'inclusion en .h dans le .h genere. Bref la
  traduction d'un .ki a lieu avant le passage dans CPP. Cette methode
  permet de generer une seule fois les fichiers .h. Avec d'autres
  methodes, on en serait arrive a regenerer plusieurs fois les memes
  .ki en .h.
  D'autre part les .k seront compiles ensuite. Les .ki inclus dans ces
  .k seront analyses (et representes sous forme de liste en memoire)
  afin de faciliter le remplacement du pointeur this et des noms des
  methodes. En aucun cas cette analyse ne donne lieu a la generation
  de .h. Pour realiser cette analyse nous avons besoin de toute la
  chaine des interface et interface virtuelle pour retrouver les
  membres pointes par this. Pour cela, chaque .ki inclus dans un .k
  est d'abord passe par CPP.

On peut constater qu'il a des taches identiques entre les deux parties
:
        - prendre un .ki et generer un flux de token (module Klex)
        - prendre un flux de token et generer une representation en
memoire des structures de donnees (module Synt)

Pour la realisation de la premiere partie, un autre module a ete
realise : Out. Il prend la representation en memoire des structures de
donnees, et genere le .h correspondant.

Pour la seconde partie, on a le module Ktest (nom temporaire). Grosso
modo ce module prend un .k en entree, et fait des grosses bidouilles
pour trouver les .ki. Ensuite pour chaque .ki il lance CPP puis lance
l'analyse du module Klex puis Synt. On se retrouve donc pour chaque
.ki inclus avec une representation en memoire des structures de
donnees. Plus tard ce module devra aussi effectuer les remplacements
de pointeur "this" et les remplacements de noms de methodes.

Pour l'analyse d'un .ki TOUS les mots sont analyses : il y a un vrai
analyseur lexical, un vrai analyseur syntaxique.
Pour l'analyse des .k on fait ca "gros goret". En effet c'est plutot
lourd de devoir analyser tous les token du langage C pour juste
effectuer quelques remplacements mineurs. Je sais pas ce que ca va
donner dans le futur, mais ca vaut le coup d'essayer.

Pour tester :

 - compiler la chose : make clean all
 - compiler un .ki   : ./kicompil fichier.ki fichier.h (et zou)
 - compiler un .k    : ca sert pas a grand chose le fichier genere est
 presque identique au fichier d'entree. par contre on peut s'amuser en
 mode interactif pour constater que le machin reconstruit bien une
 representation en memoire des structures de donnees.

Pour tester en mode interactif :
  Pour le compilo de .ki :=20
    #load "klex.cmo";;
    #load "synt.cmo";;
    open Klex;;
    open Synt;;
    let blarf =3D=20
        read_ki_file(analyze_flux(create_stream(
        open_file "test/test.ki")));;=20
=20=20
  Et zou ca genere une representation des donnes pour l'interface
  designee par test.ki (et seulement celle la).

  Pour le compilo de .k :
  C'est rigolo d'essayer parce que la representation en memoire qui
  est generee comprend l'interface designee par le .ki inclus mais
  aussi toutes les interfaces virtuelles qui sont parentes de cette
  interface.

  La c'est un peu plus chaud. Deplacer tous les fichiers du repertoire
  test/ dans le repertoire ou se trouvent les sources. Ensuite en mode
  interactif :
    #load "klex.cmo";;
    #load "synt.cmo";;
    #load "ktest.cmo";;
    open Klex;;
    open Synt;;
    open Ktest;;
    let in_flux =3D create_stream(open_file "test.k");;
    let out_file =3D open_out_file "log";;
    analyze_flux2 out_file in_flux;;
  Et zou le fichier est genere. Pour voir la liste des
  interfaces/interfaces virtuelles :
    !ki_list;;

  ATTENTION : tel quel le compilo de .k n'est pas utilisable en mode
  non interactif : il faut decommenter la derniere fonction puis
  recompiler. Les fichiers .k et .ki doivent etre dans le meme
  repertoire que l'executable, sinon il y a des problemes de chemins.

Voila, j'espere qu'on aura un peu de feedback (au moins de toi d2)
concernant ce truc pour savoir si il faut qu'on continue dans cette
voie ou non.

Les sources sont dispo dans kos-dev (pas d'integration dans le module
kos pour le moment, c'est du beta pre alpha).

A bientot,

Thomas
--=20
PETAZZONI Thomas
thomas.petazzoni@enix.org     UIN : 34937744
Projet KOS : http://kos.enix.org
Club LinUT : http://club-linut.enix.org