Styles

samedi 28 mars 2009

Délire paranoïaque de programmation

N'avez vous jamais eu envie de contrôler entièrement l'environnement informatique cible de votre programme pour être sûr à 100% de ce que vous développez ? C'est certainement le rêve d'un paranoïaque doublé d'un introverti incapable d'accepter les limites de ce monde (et de lui-même par la même occasion). Mais dans le monde en crise qu'est supposé est le notre, avoir l'entière maîtrise d'un monde binaire peut se révéler rassurant pour certains. Même si cette passion est destructrice quand on ne s'ouvre plus sur le reste du monde.

Le vrai délire créatif des paranoïaques que nous sommes, nous les informaticiens, passe par la connaissance des fonctionnements les plus bas niveau de la machine, d'arriver clairement à savoir ce qui se passe en temps réel dans chaque partie de l'ordinateur. Quelle joie alors de programmer pour une console de jeux plutôt que sur un boufficiel comme l'est un système d'exploitation commercial. C'est ce que nous rappelle Jasper Vijn dans son excellent tutoriel pour le développement GBA :
D'un point de vue programmation, le GBA (ou n'importe quelle autre console) est totalement différent d'un PC. Il n'y a pas de système d'exploitation, pas de pagaille avec des drivers et des incompatibilités avec le matériel. Ce sont des bits aussi loin que l'oeil puisse voir. En fait, les PC ne sont aussi que des bits, mais c'est plusieurs niveaux en dessous. Sur une console, c'est juste vous, le CPU et la mémoire. En gros, c'est le rêve du Vrai Programmeur.
Quand on en vient au niveau bit, on est confronté à plein de ravissantes choses comme l'ABI (Application Binary Interface) et plus spécifiquement l'EABI ARM pour ce qui est du développement pour GBA ou NDS.
La compréhension de ce qui se passe en dessous du langage de programmation de haut niveau devient nécessaire, si ce n'est obligatoire pour éviter de grosses bévues. Savoir programmer au niveau assembleur n'est pas forcément inutile quand vous êtes embarqué dans un projet de type Java ou .NET. Comprendre le bytecode et la JVM peut se révéler utile dans certains cas, notamment pour la maîtrise des performances.

C'est ce que nous montrais brillamment Peter Haggar dans son livre Mieux programmer en Java , maintenant épuisé en Français mais qui se trouve encore en version anglaise dans son livre Practical Java Programming Language Guide.

Il avait organisé son livre en ateliers avec pour chacun, un point particulier d'attention où la solution Java n'est pas aussi simple qu'elle n'y parait. Dans plusieurs de ces ateliers, la référence au bytecode produit pour expliquer le pourquoi du comment est inévitable, comme par exemple l'atelier 40 page 118 : "Utiliser System.arrayCopy pour copier des tableaux".

On peut s'en apercevoir aussi dans ses articles en ligne comme par exemple Double-checked locking and the Singleton pattern où il y a encore un deassemblage du code pour mieux comprendre ce qui se passe.

Des particularités de la machine sont à prendre en compte quand on développe si bas, comme par exemple l'alignement de données et de structures, l'endianness, les différentes méthodes de copie de données (tableaux, copie de structure (le C permet de faire de la copie de structure sans appel de fonction particulière : que se passe-t-il vraiment alors ?) , copieurs standards comme memcpy(), et des routines spécifiques à GBA ou NDS comme CpuFastSet() et le DMA).

Pour la plupart des applications de gestion de l'information (disons que la règle du 80/20 s'applique encore ici), le développeur n'a pas besoin de se soucier de tous ces détails, les langages de haut niveau (je les appellerais plutôt des langages plus abstrait) arrivant bon an, mal an à offrir des performances acceptables dans la plus part des situations les plus courantes. Mais, il y a toujours ce 20% des applications (ou disons les 20% des fonctionnalités des 20% des 80% de toutes les applications ... ) qui sont toujours importantes à maîtriser complètement sous peine de ne pouvoir délivrer le logiciel. Dans ces cas, là, deux choix s'offre à vous, puisque le monde est toujours divisé en 2 :
- soit tu creuses (tu cherches à comprendre la complexité des ordinateurs et les conséquences de tes paroles en langage de programmation)

- soit tu tiens un pistolet chargé sur un autre qui creuse (l'autre qui creuse est celui qui va maîtriser le sujet et la machine pour toi... et qui en redemandera encore après çà ;) )

Aucun commentaire: