Il nous en donnera les buts, les principales fonctionnalités et nous expliquera les problèmes auxquels il est confronté.

Voici une petite description de l’ensemble du projet :

* Nom du projet: libsubprocess

* Résumé du projet libsubprocess: Le but de cette bibliothèque est de fournir une API qui permette de réaliser des tests en boîte noire sur des programmes non-sûrs. On veut pouvoir imposer certaines contraintes aux processus qui sont lancés à travers l’interface (contrainte sur le temps d’exécution, la mémoire consommée, le nombre de processus utilisés, les appels systèmes utilisés, etc). On veut aussi pouvoir récolter des informations basique de profilage sur le programme (essentiellement le temps de calcul ainsi que la mémoire consommée).

Évidemment, libsuprocess est juste la première brique d’un tout plus important, dont voici une petite vision d’ensemble:

* Contexte général du projet: Libsubprocess doit s’insérer dans un framework plus large qui permette de tester automatiquement des projets d’étudiants. Il s’agit donc de vérifier la conformance du logiciel à des spécifications précises ainsi que de détecter le maximum de bugs ou les faiblesses d’implémentation. Et tout ceci de manière aussi automatique que possible et si possible être agnostique au niveau du langage de programmation utilisé pour coder le projet.

Le framework contiendra:

* Un framework consacré à l’insertion de limites sur l’exécution et qui assurera la collecte de données de profilage (libsubprocess).

* Un framework de test, très probablement basé sur ATF/Kyua: http://code.google.com/p/kyua/wiki/ATF

* Une framework d’isolation basé sur libvirt: http://libvirt.org/
Voir: http://libvirt.org/devguide.html

* Un framework d’analyse statique qui analyse le code des étudiants et fasse un retour pertinent (éviter au maximum les faux positifs).

* Un serveur web permettant aux élèves de déposer les différentes versions de leur projet, de consulter le résultat de certains tests (pour avoir un retour automatique sur leur code) et aux enseignants de consulter l’intégralité des tests.

Utilisation de Django+Pinax:
- https://www.djangoproject.com/
- http://pinaxproject.com/

Le but de cette plate-forme est de permette de passer à l’échelle pour l’enseignement de la programmation. Permettre à tous les élèves d’avoir des projets individuels et de ne pas avoir besoin de tas d’enseignants qui passent dans les rangs pour dire: 1000x »Vous avez oublié de fermer cette parenthèse ».

de notre projet.

Au programme de la semaine prochaine, il y aura plus d’implémentation.

En effet les tâches distribuées sont :

- évaluer la viabilité de modéliser les griffes soit par une augmentation de l’adhérence du bout des pattes, soit par une fixation pure et simple de celles-ci dans l’espace

- évaluer la viabilité de modéliser la contraction des muscles, par un changement des caractéristiques du ressort représentant le muscle, par l’application d’une force aux pattes concernées ou par la modification de la position des griffes

- développer une structure nous permettant de représenter  et de sauvegarder notre individu

Il serait aussi temps de penser à un nom pour ce projet (CheapMonk ?).

Lors de cette séance nous déciderons du langage de programmation et des différents choix concernant l’environnement graphique et le moteur physique.

Comme d’habitude rendez-vous en TD6 à 18h30.

Venez nombreux en TD6 à 18h30.

Rendez-vous à 18h30 en salle TD6

Plus d’informations:

• http://www.youtube.com/watch?v=wQ9xd4sqVx0
• http://www.rhoban-project.org/

http://gregwar.eirb.fr/GCC.tgz

Introduction

GCC est un outil permettant de compiler du code source C en code binaire éxécutable. Ce processus passe par plusieurs étapes:

1. Précompilateur, étape visant à interpréter les macros, les inclusions et toutes les directives commençant par « # ». Produit un autre fichier C moins riche. On peut stopper GCC à cette phase avec -E.
2. Compilation à proprement parler, produit un fichier en code assembleur (.s) à partir du fichier C précédent.  On peut stopper GCC à cette phase avec -S.
3. Assemblage, produit un objet (.o) à partir du code assembleur. Ce travail est fait par l’utilitaire as. On peut stopper GCC à cette phase avec -c
4. Edition des lien, assemble les objets en un programme éxécutable, ce travail est fait par l’utilitaire ld. GCC va par défaut jusqu’à ce point et produit un binaire

Notons que les deux dernières étapes sont totalement gérées par des outils externes, GCC faisant directement appel au programmes as et ld. Le « coeur » du travail de GCC se fait à l’étape 2, et correspond à la production de code assembleur à partir du code C.

Notons également que GCC est capable de reprendre un fichier de n’importe quelle de ces phases, on peut ainsi compiler ensemble un objet avec un fichier C et du code assembleur à l’aide de la même commande.

Pour comparer les optimisations de GCC, on appliquera donc le flag « -S » pour stopper la compilation à la production du code assembleur. On compilera ainsi avec et sans les optimisations (avec et sans le flag -O3) afin de pouvoir visualiser les différences dans le code produit

Optimisations

Nous allons étudier les différents exemples présents dans l’archive présentée ci-dessus.

Les mouvements conditionnels (cf 01_cmov.c)

Le code d’un programme est lu linéairement par le microprocesseur. Ce dernier est doté d’un mécanisme nommé pipeline, qui permet d’anticiper les calculs en calculant des instructions avant de les rencontrer réellement. Cependant, un code source est doté d’embranchements conditionnels qui empêchent la prédiction de se faire.

En tant qu’optimiseur, on voudra donc minimiser le plus possible ces embranchements en utilisant diverse stratégies.

Le premier exemple montre que GCC préférera, en mode optimisé, produire du code assembleur contenant des instructions de mouvements conditionnels (cmov*) que du code contenant des embranchements avec des sauts.

Un mouvement conditionnel sera systématiquement éxécuté par le microprocesseur: si le flag de comparaison est vrai, il fera le déplacement, autrement, il ne fera rien.

Le déroulage des boucles (cf 02_unroll.c)

Une boucle est traduite en assembleur (pour simplifier) par une série d’instructions suivi d’une condition et d’un embranchement à prendre si la condition n’est plus vérifiée.

Certains boucles font un nombre de tour prévu à l’avance, lorsque le nombre de tour dépend d’une macro (cf define et sizeof) par exemple. Lorsqu’elles sont suffisament petites, GCC peut choisir de dérouler le contenu d’une boucle, en répétant X fois le code en ayant substitué l’indice.

L’intégration des fonctions (cf 03_inline.c)

L’appel à une fonction peut se traduire dans le code assembleur par une manipulation de registres, de la pile etc. Lorsque des fonctions sont très courte, GCC peut les incorporer aux fonctions les apellant, c’est à dire recopier leur code directement au lieu de vraiment y faire appel.

Le précalcul des valeurs (cf 04_precalc.c)

Certain calculs ne dépendent d’aucune variable définies dynamiquement pendant l’éxécution et donneront toujours le même résultat. GCC va donc précalculer ces valeurs pour les placer directement dans le code binaire.

L’exemple fournit montre ce phénomène dans le cas d’une boucle faisant la somme des 10,000 premiers entiers.

En tant que développeur, il n’est donc pas nécéssaire de faire ces précalculs, car il est parfois plus pratique de pouvoir changer le calcul (la valeur 10,000 dans ce cas par exemple) que le résultat.

A travers une dizaine d’exemples, je montrerai la manière dont GCC est capable d’optimiser le code binaire produit en comparant le résultat avec et sans l’activation des optimisations.

Rendez-vous en amphi C à 18h30 à l’ENSEIRB

Venez nombreux !

[Màj]
Les supports utilisés lors de cette présentation sont disponibles à l’adresse suivante :
http://www.labri.fr/perso/tabary/cours/1011/secu_csi/cours10.pdf

Samuel Thibault est chercheur au LaBRI, membre de l’équipe RunTime de l’INRIA de Bordeaux et enseignant à l’Université de Bordeaux. Contributeur du projet GNU Hurd, il oriente sa recherche sur la gestion des threads et plus particulièrement leur ordonnancement.

Lors de la geekerie du mardi du 12 avril, Samuel Thibault raconte “l’histoire d’un `a’ …” : le cheminement d’un caractère de la pression d’une touche à son impression sur l’écran.

Lorsque l’on tape sur une touche de notre clavier, la lettre imprimée sur la touche se retrouve affichée à l’écran. Nos ancêtres auraient tout simplement utilisé une ficelle qui tire un masque pour obtenir cet effet. Plus récemment, dans les machines à écrire, c’était une tige de métal qui propulsait un caractère vers un ruban imbibé d’encre situé au-dessus d’une feuille. Il se trouve qu’entre-temps on a développé des trésors d’ingéniosité pour rendre cela infiniment plus complexe…

Je raconterai donc Mardi 12 l’histoire de cet héroïque ‘a’ tout au long de ses exploits, depuis la touche sur laquelle il est imprimé, jusqu’à l’écran qui l’affiche. Le cas pris en exemple ne sera pas forcément exactement ce qui se passe dans votre machine, puisque cela dépend par exemple de la connectique de votre clavier (AT, PS/2, ou USB), on verra donc surtout les principes.

Le niveau de détail pourra varier selon les demandes. A priori je pense étudier les niveaux matériels, tty et graphisme. On pourra selon le temps voir les aspects réseau voire Internet.

Un teaser peut être lu sur http://dept-info.labri.fr/~thibault/a.html