Haskell et cross-compilation

Version imprimable

23/06/2009, 23h19
limestrael

Haskell et cross-compilation

Salut les gens !
J'aurais voulu savoir si il y avait (facilement) moyen de compiler du code haskell pour une autre architecture.
En l'occurrence, il s'agit d'un micro-controlleur AVR (plateforme Arduino pour ceux qui connaissent). Il est codable très faciment en C/C++, du coup j'aurais voulu coder la couche machine (communication avec les capteurs/moteurs/etc.) en C et lui faire utiliser des fonctions initialement codées en haskell (qui, elles, s'occuperaient de l'intelligence du "robot").
Du coup, va falloir aussi que je voie comment interfacer C et Haskell.
Je ne sais pas si quelqu'un ici a déjà essayé de cross-compiler en haskell.

ghc me génère juste le code C (le .hc) avec l'option "-C", mais je ne peux pas me contenter de compiler ça directement avec avr-gcc, il me manque aussi tout le coeur de haskell (les libs de base, quoi).

J'ai vu sur le net des gars qui tentaient par exemple de cross-compiler pour une archi ARM. Ca n'avait pas l'air simple...

EDIT: Je viens de voir qu'il existe un compilateur haskell nommé jhc (il utilise ghc), qui, lui, supporterait la cross-compilation. Quelqu'un connait ?
24/06/2009, 11h30
Twinside

Euh t'es sur que le micro-contrôleur a assez de puissance sous le capot pour s'enquiller le Garbage Collector et l'évaluation paresseuse?

Quand je regarde les spec du bidule, j'ai un peu peur quand même
24/06/2009, 14h40
Jedai

Je suis d'accord avec Twinside : Haskell n'est pas vraiment adapté à la programmation de micro-controlleurs comme celui-ci. Vu les quantités de mémoires et la fréquence, il te faut un contrôle complet du matériel, seul les langages prévus dans cet objectif sont envisageable (C, C++ (avec pas mal de limitations), Ada....).

Par contre, l'un des domaines où un certain nombre de gens ont eu de beaux succès avec Haskell, c'est d'écrire un EDSL à partir duquel ils génèrent le code C destiné à leur micro-controlleur, ils ont généralement constaté une grande amélioration de la facilité de programmation, de la fiabilité du code produit et du volume de code à maintenir. Je te reporte à Atom pour un exemple de réussite.

--
Jedaï
24/06/2009, 15h47
limestrael

Citation:

Envoyé par Jedai

Par contre, l'un des domaines où un certain nombre de gens ont eu de beaux succès avec Haskell, c'est d'écrire un EDSL à partir duquel ils génèrent le code C destiné à leur micro-controlleur, ils ont généralement constaté une grande amélioration de la facilité de programmation, de la fiabilité du code produit et du volume de code à maintenir. Je te reporte à Atom pour un exemple de réussite.Jedaï

Oui, en fait c'est ça en ce moment que je cherchais à faire (comme je le disais, le code source C généré par GHC n'est pas directement utilisable). Je suis d'accord avec vous qu'un microcontrolleur ne supporterait pas directement du haskell. Je suis également tombé sur le compilateur nhc98, qui est supposé généré du code léger (pour un microchip c'est une bonne chose), mais j'arrive pas à le compiler.

Mais oui, compiler mes progs haskell en passant par du C est une bonne solution, et c'est ce que je comptais faire, en faire (je me suis mal expliqué, il me semble).

Sinon, que signifie "EDSL" ?
24/06/2009, 16h40
Jedai

Tu te méprends, je n'ai pas parlé de compiler du Haskell vers du C puis de compiler ce C pour ta plateforme. Quelque soit la méthode de compilation d'un langage, il n'en devient pas magiquement plus léger... Haskell est un langage de très haut niveau, qui se repose sur des concepts peu compatibles avec un micro-contrôleur aussi limité que celui sur lequel tu travailles (le principal problème étant la mémoire : le garbage collector et les structures de données paresseuses par défauts ne sont pas adaptés à un environnement comme le tien où chaque ko compte).

J'ai parlé d'écrire en Haskell du code qui va générer du C, l'une des approches les plus agréables pour ceci étant de créer un DSL, c'est à dire un Domain Specific Language (un langage spécialisé pour un tâche donnée, dans ton cas décrire une AI basique ?), et plus particulièrement un EDSL, Embedded DSL, c'est à dire un DSL pour lequel on n'écrit pas de lexer/parser mais qu'on intègre directement dans le langage, s'offrant ainsi une flexibilité et une expressivité bien supérieure. C'est l'approche choisie par Atom (qui d'ailleurs semble relativement proche de tes besoins pour le peu que j'en sais et ce que tu nous as dit) pour Eaton avec d'excellents résultats (par rapport à leur infrastructure antérieure).

--
Jedaï
24/06/2009, 18h06
limestrael

OK ! Effectivement, j'avais pas du tout compris ça.
Désolé, je suis un peu lent à comprendre, on dirait ;)

Je ne connaissais pas ce concept. Y aurait-il des explications sur les principes généraux de l'EDSL (genre tuto) sur le net ? Parce que là c'est un peu flou pour moi, pour savoir ce que je vais devoir faire... Si je comprends bien, cela consiste à utiliser Haskell comme un méta-langage ?

En fait, je n'ai pas de but précis en tête. Ce que je veux, c'est pouvoir programmer (en partie) mon microcontrolleur en haskell. Par "en partie", j'entends le haut-niveau du code (la couche d'abstraction serait faite en C/C++).
En fait, une fois qu'on a la partie du code qui gère le matériel (les fonctions "non-intelligentes", vu qu'elles s'occupent juste de traduire ce que veux faire en signaux analogiques/numériques vers et depuis les capteurs, en écritures/lectures dans des registres, etc.), il ne reste plus que la logique du programme (la logique métier) à coder, en l'occurence en haskell.

EDIT: Je jette un coup d'oeil à Atom, mais je ne trouve pas de doc sur son champ d'application exact et surtout comment l'utiliser...

EDIT2: On dirait qu'un gars appellée John Van Enk a déjà bossé en Haskell exactement sur la même plateforme que moi avec Atom : http://blog.sw17ch.com/wordpress/?p=84
25/06/2009, 10h01
Jedai

Citation:

Envoyé par limestrael

Je ne connaissais pas ce concept. Y aurait-il des explications sur les principes généraux de l'EDSL (genre tuto) sur le net ? Parce que là c'est un peu flou pour moi, pour savoir ce que je vais devoir faire...

L'EDSL n'a pas de règles générales, ce qui fait sa force c'est son adéquation au domaine précis auquel il se destine. En Haskell, il est courant de voir des EDSL sous forme de monades, avec des combinateurs d'ordre supérieurs.

L'idée du DSL, qu'on a vu fleurir à bien des endroits ces dernières années, c'est que les langages généralistes ne seront jamais aussi précis et facile à utiliser qu'on pourrait le souhaiter. Souvent on n'emploie qu'une partie de leurs facultés et leur structure complique une tâche pourtant simple tant qu'on reste dans un seul domaine. Alors pourquoi pas écrire un mini-langage qui ne sait faire qu'une chose mais qui le fait bien et clairement.

Citation:

Envoyé par limestrael

Si je comprends bien, cela consiste à utiliser Haskell comme un méta-langage ?

Exactement ! Les expressions de l'EDSL sont manipulables par du Haskell classique et on peut intégrer du Haskell dans ces expressions tout aussi facilement.
Comme Haskell est très puissant et offre par ailleurs un système de type très expressif, on se retrouve avec un excellent environnement pour un EDSL. C'est ainsi que les ingénieurs de chez Eaton ont réussi à réduire incroyablement la taille de leur code (de 120_000 lignes en MatLab, SimuLink et VB à 5_000 lignes en Haskell+Atom) tout en obtenant un résultat extrêmement fiable (le code généré par Atom a réussi tous les tests électroniques et logiciels du premier coup). Leur 3_000 lignes d'Atom génèrent 22_000 lignes de C, mais il faut bien voir également que ce C est parfaitement incompréhensible par rapport au Atom qui le génère : c'est l'équivalent de bien plus de lignes en C si on l'écrivait à la main pour être compréhensible et possible à maintenir, sans parler d'apporter les mêmes garanties que le code Atom.

Citation:

Envoyé par limestrael

En fait, une fois qu'on a la partie du code qui gère le matériel (les fonctions "non-intelligentes", vu qu'elles s'occupent juste de traduire ce que veux faire en signaux analogiques/numériques vers et depuis les capteurs, en écritures/lectures dans des registres, etc.), il ne reste plus que la logique du programme (la logique métier) à coder, en l'occurence en haskell.

EDIT2: On dirait qu'un gars appellée John Van Enk a déjà bossé en Haskell exactement sur la même plateforme que moi avec Atom : http://blog.sw17ch.com/wordpress/?p=84

Atom me semble plutôt adapté à ce que tu demandes, si je comprends correctement tes besoins, mais il faudrait nous en dire plus sur ton objectif pour en être certain.

(NB : John Van Enk travaillait avec la version 0.0.2 d'Atom, la version actuelle est la 0.0.5 et comprend déjà toutes les modifications qu'il suggérait à l'époque)

--
Jedaï
25/06/2009, 11h00
limestrael

Merci beaucoup pour toutes ces infos ! Je me pencherai donc plus activement sur Atom.

La seule chose qui m'embête, c'est que j'ai l'impression que je vais devoir sur-utiliser les Monades, et du coup me retrouver à coder dans un style plus proche de l'impératif, alors que je voulais justement pouvoir faire ça pour coder en fonctionnel.

Citation:

Envoyé par Jedai

Atom me semble plutôt adapté à ce que tu demandes, si je comprends correctement tes besoins, mais il faudrait nous en dire plus sur ton objectif pour en être certain.

Là, comme je l'ai dit, je ne peux pas être très spécifique, vu que je n'ai pas encore d'idées concrètes. Disons que je cherche à expérimenter, et je verrai ensuite.