09

Déambulations algorithmiques

mar
3 Comments » |  Posted by Etienne SOBOLE |  Category:Divers Infos, Ebola

Salut.
Après quelques 2 ans d’absence me revoilà ;) D’autres centres d’intérêts avait absorbés une part importante de mon énergie, mais papillonner dans le monde informatique en perpétuelle recherche de futiles expérimentations a fini par me manquer. On ne peut pas finalement limiter sa vie à ne faire des trucs utiles. Les projets foireux sans aucun buts ont eux aussi leur importance.
Alors voilà, ça m’a pris comme une envie de pisser, je vais me lancer (une nouvelle fois) dans l’expérimentation des compilateurs. Ça n’aboutira peut être pas à grand chose, mais si ça peu aider quelques personnes tant mieux.

Le projet fou

Mon langage va s’appeler Ebola, car c’est le langage qui tue.
Comme tout projet qui se respecte, on a toujours d’énormes espoirs au commencement (sinon on ne commencerait pas !) ;)

La syntaxe du PHP

Je fais du PHP à peu près tous les jours de ma vie. Finalement et même si c’est pas aussi amusant que l’assembleur, j’aime bien ce langage.
Parmi les points fort du PHP on notera:

  • C’est un langage très simple qui a une syntaxe assez proche du C++ (en opposition à des langages tordus comme le LISP et autres experimentations)
  • Les variables globales n’existent (presque) pas puisque toutes les variables sont par défaut considérées comme locale. Faut vraiment se forcer pour faire une variable globale en PHP.
  • Le code est très lisible puisque les variables sont clairement identifiées par le caractère $.
  • Les variables ne sont pas typées (ce qui n’est d’ailleurs pas gage de qualité ni de performance) et ne doivent pas, par conséquent, être déclarées. L’écriture de programme PHP est donc assez, rapide.

Donc je vais essayer de “m’approcher” de la syntaxe du PHP pour d’écrire mon langage.
Je m’autorise tout de même quelques ajouts (et retrait) en cas de besoin…

L’assembleur

Je suis assez nostalgique du BBC BASIC de l’Archimède qui permettait de basculer du Basic à l’assembleur de la manière la plus simple qui soit
Même si je ne me souviens plus trop de la syntaxe, cela ressemblait a un truc dans ce genre.

REM Here Is the BBC BASIC
A = 100
B = 50
P%=code
[
.program
         MOV r0, A
         MOV r1, B
         ADD r0, r0, r1
]
... continue le code BASIC

Autant dire qu’il est difficile d’imaginer plus simple.

Donc mon langage devra permettre d’inclure de l’assembleur (cela ne sera peut être pas fait de façon aussi simple mais bon).

Android, iOS et les autres…

J’ai eu l’occasion d’essayer Corona SDK.
J’ai trouvé cet environnement de développement tellement simple et cool, que je pense qu’il n’est plus envisageable de développer une application pour une plateforme spécifique.
A présent j’adhère totalement au concept d’environnements de développement cross plateforme.

Alors soyons fou, j’aimerai créer un langage qui puisse s’exécuter sur plusieurs plateformes.
Cela ne va pas sans poser quelques problèmes, surtout si on envisage d’intégrer de l’assembleur.

Un compilateur, c’est quoi ?

Wikipedia donne une excellente définition de ce qu’est un compilateur.

Un compilateur est un programme informatique qui transforme
un code source écrit dans un langage de programmation (le langage source)
en un autre langage informatique (le langage cible).

Entendez par là qu’un compilateur ne génère pas forcément du code assembleur directement utilisable par le processeurs de votre ordinateur.
On connait tous (malheureusement) le compilateur le Java qui transforme le code en byte code (une sorte de code assembleur générique) qui va par la suite être interprété (on plus exactement compilé à la volée) sur le matériel auquel le programme est destiné.
Un autre exemple est Corona SDK qui va transformer le code lua en un autre code de haut niveau (Objective C pour l’Iphone, Java pour Android, C# pour WindowPhone) afin que les compilateurs respectifs de des environnement sur lesquels ils tournent puissent compiler finalement le programme Lua. Enfin, a moins qu’il n’y ai un interpréteur LUA auquel cas, c’est nettement moins bien…

L’approche de la conversion dans un langage cible qui serait compilé finalement par un compilateur tiers est une approche assez séduisante.
Par exemple on pourrait imaginer que mon langage soit finalement (dans un premier temps) converti en C (ou C++) pour être exploité par le compilateur Android.

Le principal avantage de cette approche est qu’une énorme partie du travail (d’optimisation entre autres) est reportée sur le compilateur C (ou C++), qui produira probablement un code plus efficace que celui que je pourrais produire. Bon évidement, si vous êtes un génie de l’informatique sur le point de révolutionner l’optimisation des compilateurs, je ne peux que vous inviter à réaliser vous même votre propre compilateur.
Dans mon cas, il y a peu de chance que ça arrive.

Le principal inconvénient, c’est l’aspect usine à gaz du procédé.
En gros on va devoir générer a partir du code source l’intégralité d’un projet Android afin de pouvoir le compiler.
Bon, on n’est pas à ça prêt… J’ai déjà fait pire…

Cross assembleur

Le problème de faire un langage cross Plateforme étant réglé, il nous reste plus qu’à résoudre le problème de l’assembleur (inline).
Le langage assembleur se marie assez mal avec le concept cross plateforme vu que le premier est totalement dépendant de ladite plateforme.
Rien que sur Android, vous êtes susceptible de tomber sur

  • Un processeur ARM 32 bits
  • Un processeur ARM 64 bits
  • Un processeur Intel
  • Et je ne parle même pas des Mips et autres Tegra fonctionnant sans NEON (bon même s’il ne doit pas en rester des masses en circulation).

    Donc ça semble pas gagné notre affaire :)
    Bon alors, je fais quoi?

    • 1 : Je laisse tomber : Je pourrais simplement dire qu’on laisse tomber cette idée d’assembleur inline version BBC Basic. Mais c’est pas du tout le plan ça…
    • 2 : Assembleur Générique : Je pourrais imaginer une sorte d’assembleur intermédiaire avec des instructions génériques. Sauf que tous les procs n’ont pas du tous les même instructions ni même nombre de registres. NEON et SSE ont juste rien à voir. Au final ça ne ressemblerai plus du tout à un assembleur mais a un autre de haut niveau.
    • 3 : La surcharge de langage : Un langage qui permettrai de surcharger un code avec une version optimisé pour un processeur particulier. Ça c’est le TOP même si cela va donner une surcharge de travail au développeur.

    Bon évidement on va opter pour la 3eme version.
    Malheureusement, il va falloir faire quelques concession, car le mixage Ebola / Assembleur ne va pas pouvoir se faire a n’importe quel moment sous peine de devenir illisible. On va donc se contenter de fonction assembleur.

    Bon ben a quoi ça va ressembler alors?

    Bon voilà les bases sont posées à présent

    Et le hello world alors ?
    Le code pourrait ressembler à un truc dans ce genre.
    J’y ai mis une fonction Ebola (php ?!?) et ses versions ARM 32 bits et Intel.

    $x = 10;
    $y = 12;
    $result = Addition($x, $y);
    
    $chaine = "Hello 10 + 12 = $result";
    
    echo $chaine;
    
    function Addition($x, $y)
    {
             return $x + $y;
    }
    
    arm32 Addition($x, $y)
    {
             add        r0, r0, r1
             mov        pc, lr
    }
    
    intel86 Addition($x, $y)
    {
             add         eax, #$y
             ret
    }
    

    Déjà si un jour ce code affiche quelques chose sur mon LG G3.
    Je serait content…

    3 Responses to “Déambulations algorithmiques”

    1. Eric dit :

      Si on fait de l’assembleur, c’est pour implémenter un algorithme avec une “résolution” plus fine qu’en C, par l’utilisation de capacitées intrinseques au microprocesseur. Généralement, ca nous oblige aussi a repenser la structure de donnée ( particulierement vrai en simd).

      Donc l’asm géneric, ca n’a pas beaucoup d’interet.

      faire un code séparé par microprocesseur c’est deja ce qu’on fait, mais mis dans des fichiers séparé.

      Le mettre dans le meme fichier, Pas sur que ce soit le langage qui tue !

    2. Etienne SOBOLE dit :

      Ouaip.
      Ça se tient ce que tu dis ;)

      Mais disons que le concept de compilateur et de linker n’est pas à la portée de tout le monde.
      L’assembleur non plus évidement.

      Ce que j’aimerai bien faire c’est un langage facile à utiliser. Un truc qui ne nécessite pas Bac + 5 juste pour compiler un simple “Hello World”.
      Bon… c’est le projet.

    3. Eric dit :

      Oui, mais qu’elle est l’objectif visé de l’insersion d’asm dans du C ? Sachant que le gnu le fait déjà de façon fiable, avec liens entre variable et registre, en entrée comme en sortie. C’est tout a fait praticable pour des petites routines.

    Répondre

    Human control : 7 + 3 =