{{{
COMPTE RENDU DE LA REUNION DU 16 Juin 2009

-----------------------------------------------------------------
A) Présentation: Interfaçage d'IP.

     Tanguy Risset a présenté la contribution que le CITI propose
  à COACH.  Cette présentation est disponible sur le site
  http://yaka.ensiie.fr/coach.
  Le CITI propose d'intégrer à COACH un système pour interfacer
  un coprocesseur matériel à l'application tournant sur le SoC.
  Les problèmes essentiels sont:
    - comment alimenter efficacement le coprocesseur (profiter
      du mode busrt et des schémas d'échanges du coprocesseur).
    - comment interfacer le coprocesseur au logiciel pour ne
      pas avoir de driver système à écrire.
  Le CITI envisage de créer un DMA "intelligent" qui connaissant
  le schéma d'échange du coprocesseur avec l'extérieur optimise
  ceux-ci.
  La contrainte est que le coprocesseur doit avoir un schéma
  d'échange fixe, c'est à dire qui ne dépend pas des données
  qu'il reçoit.

  L'intégration de cet interfaçage à COACH a soulevé 2 problèmes:
    - COACH visant l'implantation d'une application dans un SoC sur
      FPGA.  L'application est un réseau de tâches communiquant
      par l'intermédiaire de FIFO et le matériel visé est un
      sous-ensemble des composants SoCLib. De ce fait les
      communications sont déjà définies dans SoCLib (protocole et
      bibliothèque srl).
      Est-ce une bonne idée d'implanter un second schéma de communication?
      Après discussion, Tanguy n'a soulevé aucune objection pour
      utiliser le protocole physique srl dans le composant
      d'interfaçage ce qui fait que son utilisation sera transparente
      pour l'utilisateur final de COACH. 
    - Autre question soulevée, ce composant est-il un concurrent
      du MWMR de SoCLib? En fait, la réponse est non. Les MWMR passent
      leurs temps à ce battre pour prendre les locks sur les FIFOs.
      Ce composant peut donc être vu comme un MWMR intelligent dans
      le cas où le schéma d'échange est statique.
 
  Ces 2 problèmes étant résolus, cette contribution apporte un plus
  au projet.
  
-----------------------------------------------------------------
B) Présentation: Structures de GCC

     Dominique Heller a présenté les structures de données de
  GCC et comment GCC les chaîne et les optimisations qu'il
  fait sur chacune d'elle. Cette présentation est disponible sur
  le site http://yaka.ensiie.fr/coach.
  
  Il y a trois structures principales correspondant à:
    - arbre syntaxique (seulement pour le C).
    - arbre syntaxique abstrait
    - Control Data Flow Graph

  Sur chacune de ces structures GCC fait des transformations
  (construction des boucles, passage en SSA, élimination du
   branches morte, transformation polyédrique, ...)
  plus on avance, plus le modèle mémoire s'éloigne du source
  initial.

  GCC est très configurable. Chaque transformation et chaque
  traitement peut être vu comme un module, que l'on peut activer
  ou désactiver par un fichier de configuration.
  On peut également ajouter facilement des modules.

  Il est donc aisé d'ajouter un module:
    1) qui dumpe une des structures après avoir fait les
       optimisations désirées
    2) qui est un outil de HLS et travaille directement sur les
       structures de GCC.
  Le problème du 1) est où s'arrête-t-on dans GCC et on revient
  problème du format (au sens sémantique) commun des outils de COACH.
  Le 2) a les avantages suivants: a) un outil de HLS de COACH peut
  s'intercaler où il veut dans la compilation GCC; b) le format
  d'échange est tout défini, c'est les structures de données de GCC.
  Mais il soulève aussi de sérieux problèmes: a) Lourdeur les structures
  de données de GCC sont complexes; b) une fois qu'une version de GCC
  aura été choisie, il sera difficile d'en changer si ses structures sont
  modifiées; c) difficulté de repasser d'un CDFG à un AST (sens inverse
  des phases GCC); d) Si une information n'est pas prévue dans les
  structures de données de GCC (tel le cycle d'une opération)
  impossibilité de l'ajouter.

-----------------------------------------------------------------
C) Actions pour la réunion du Jeudi 16 Juillet

  Pour tous, réfléchir au format d'entrée et l'interfaçage avec
  GCC. Pour cela voir les 2 papiers sur graphite envoyés par Philippe
  et sur le site HTTP.

  Paul, Christophe et Ivan doivent envoyer à Dominique un bench pour
  qu'il dumpe ce que GCC en fait à différents niveaux.
  L'analyse de ces dumps et de ces benchs seront fait pendant la réunion
  de Juillet.

-----------------------------------------------------------------

}}}