Journal Alpha: une machine bêta avec écran.

Posté par  . Licence CC By‑SA.
Étiquettes :
57
25
fév.
2013

Cher Nal,

Ce semestre j'enseigne avec joie et entrain l'assembleur. Pas en x86 ou une de ses variantes mais sur une machine abstraite nommée béta développée dans le cadre du cours Computation Structures au MIT. Elle a comme avantage d'être simple et de disposer d'un assembleur/simulateur de bonne qualité: BSim. Ce dernier fait visiblement le bonheur des adeptes d'architecture, mais dans le cadre d'un cours d'assembleur, c'est une autre histoire. Il souffre en effet de quelques limitations gênantes. La principale étant le manque d'interaction entre le programme simulé et l'utilisateur. Mis à part son affiche de la mémoire et des registres, il n'émule qu'un terminal que de quelques lignes ne supportant que getchar et putchar. De surcroit, il est closed-source.

Pour proposer à mes étudiants autre chose que du "oh regardez, l'octet à l'adresse 1234 vaut maintenant 0x42!", j'ai entrepris le développement d'une machine virtuelle permettant un affichage graphique un peu plus riche. L'objectif est de pouvoir faire tourner des petits jeux style Space Invaders dessus. Je l'ai donc dotée d'un écran supportant un mode texte en 80x30 et un mode graphique, manipulables via une mémoire vidéo. Elle est 100% compatible avec les specifications de bêta, mais ce n'est qu'une machine virtuelle et pas un assembleur: BSim est toujours nécessaire pour générer le binaire.

Elle est écrite en scala, tourne sur la jvm et a été testée sur openjdk-6 et 7, sur Arch GNU/Linux, Mac OSX et Windows 7. Bien entendu, le code est placé sous une licence libre (GPLv3+). Pour ceux que ca intéresserait, code, documentation, exemples et binaire sont ici. Dans l'espoir que ce soit utile a quelqu'un.

  • # Dommage

    Posté par  . Évalué à 4.

    Je sais bien que le C a gagné par rapport à Ada, mais c'est dommage que Beta n'ai pas les instructions avec un TRAP en cas de débordement entier comme le MIPS a.

    • [^] # Re: Dommage

      Posté par  (site web personnel) . Évalué à 3.

      C'est vrai cela permet de passer en auto-teste en cas de débordement d'entier dont tu n'as rien à faire…

      "La première sécurité est la liberté"

      • [^] # Re: Dommage

        Posté par  . Évalué à 2.

        C'est vrai cela permet de passer en auto-teste en cas de débordement d'entier dont tu n'as rien à faire…

        Bah, la plupart du temps tu ne calcule pas pour le plaisir de calculer mais tu utilise le résultat donc entre avoir (1)un core-dump ou (2)un résultat faux, je préfère (1) merci.

        • [^] # Re: Dommage

          Posté par  (site web personnel) . Évalué à 2.

          Sauf en exploitation ou sur un système "temps réel", tu préfères qu'il continue de fonctionner malgré le glitch.

          "La première sécurité est la liberté"

          • [^] # Re: Dommage

            Posté par  . Évalué à 2.

            Sauf en exploitation ou sur un système "temps réel", tu préfères qu'il continue de fonctionner malgré le glitch.

            Sauf que .. le débordement entier en C étant indéfini, tu n'as pas de garanti qu'il continue de "fonctionner": dans certains cas, ça se traduit par des boucle infinies par exemple.

            • [^] # Re: Dommage

              Posté par  (site web personnel) . Évalué à 3.

              Il est parfaitement défini. Il s'agit de l'arithmétique en complément à 2 qui fonctionne avec les joies des calcul sous modulo ou (a+b)%c = a%c + b%c, si je me rappelle bien. Cela permet d'avoir des débordements intermédiaires sans conséquence sur le résultat finale.

              Tes histoires de boucles infinis ne sont pas lié à des mélanges signed/unsigned ?

              "La première sécurité est la liberté"

              • [^] # Re: Dommage

                Posté par  . Évalué à 5.

                Il est parfaitement défini. Il s'agit de l'arithmétique en complément à 2

                Tu as tout faux, ça c'est vrai pour les débordement des unsigned, pour les débordements des entiers signés, c'est indéfini.
                Il y fut un temps où les compilateurs n'était pas très intelligent donc en pratique les débordements des entiers signés revenaient à du modulo 2, mais cela a changé..
                Si tu lis l'Anglais je te conseille ce blog: http://blog.regehr.org/

                • [^] # Re: Dommage

                  Posté par  (site web personnel) . Évalué à 3.

                  Merci pour le lien. En fait, les cpu sont toujours en arithmétique en complément à 2, mais les compilateurs jouent sur la norme C, ce qui devient faux, après activation des optimisations !

                  "La première sécurité est la liberté"

              • [^] # Re: Dommage

                Posté par  . Évalué à 5.

                (a+b)%c = a%c + b%c

                ça choque personne ?
                si je choisis c=10, a=7, b=8, ça marche pas.

  • # MMIX ?

    Posté par  (site web personnel) . Évalué à 5.

    Pourquoi ne pas proposer d’étudier l’assembleur à l’aide de MMIX ? Au passage tu pourrais conseiller la lecture de TAOCP à tes élèves.

    http://www-cs-faculty.stanford.edu/~uno/fasc1.ps.gz

    • [^] # Re: MMIX ?

      Posté par  . Évalué à 2. Dernière modification le 26 février 2013 à 09:55.

      Bof, en regardant Beta je me disais justement que c'était mieux que MMIX car plus proches des RISC existants: jeux d'instructions sur 32 bit et non pas 40 bit, 32 registres entiers contre 256 mixtes.

      Le seul truc bizarre de Beta c'est le manque de registre pour la Carry, c'est pourtant une caractéristiques de quasiment tout les CPU!

      • [^] # Re: MMIX ?

        Posté par  (site web personnel) . Évalué à 3.

        Les registres spéciaux contenant les carry et autre résultat de test utilisé comme prédicat sont une vrai plaie pour les pipelines car cela créait une dépendance forte entre 2 instructions (celle qui génère la carry et la suivante, chaque instruction pouvant modifier ces bits). Donc, c'est pas plus mal :)

        "La première sécurité est la liberté"

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: MMIX ?

            Posté par  (site web personnel) . Évalué à 1.

            Tu peux simuler le même comportement avec des instructions cmp*.

            Concernant les ref, on s'en était aperçu sur le f-cpu et lu sur de la doc ARM.

            "La première sécurité est la liberté"

    • [^] # Re: MMIX ?

      Posté par  . Évalué à 2.

      Premièrement car je ne connaissais pas MMIX. Je l'avoue, je n'ai pas (encore) lu The Art of Computer Programming. Donc merci pour l'info. Deuxièmement, après avoir lu sa spécification, il est nettement plus complexe que l'assembleur bêta, trop complexe pour ce cours. Bêta est extrêmement simple: uniquement 32 instructions, pas de cache ni flottants. Toute l'architecture peut facilement être expliquée en une ou deux heures, ce qui laisse le champs libre pour le reste. Cela dit, dans le but de former des professionnels de la programmation en assembleur moderne, introduire MMIX semble être judicieux.

      • [^] # Re: MMIX ?

        Posté par  (site web personnel) . Évalué à 1.

        Qui peut le plus, peut le moins, non ? Rien n’empêche de se limiter uniquement à un sous-ensemble d’instructions, quitte à dire explicitement que le cours ne vise pas à présenter l’ensemble des notions que permet d’aborder l’outil.

        • [^] # Re: MMIX ?

          Posté par  . Évalué à 2.

          Qui peut le plus peut le moins certes … mais pas toujours facilement. Le but est qu'ils puissent comprendre la machine et écrire des programmes rapidement, sans avoir à introduire de MMU, gestion des interruption ou dépassements au premier cours. C'est aussi pour cela qu'on préfère commencer par leur apprendre des langages plus accessibles (Haskell ou Scala en première année ca pourrait être fun ;) ) et introduire les difficultés une à une.

          • [^] # Re: MMIX ?

            Posté par  (site web personnel) . Évalué à 3.

            Je ne suis pas sûr qu’enseigner un langage orienté (ou purement) fonctionnel en première année serait nécessairement plus déroutant qu’un langage impératif/objet. J’ai même souvent entendu dire (mais je n’ai par contre jamais vu passer d’étude sérieuse sur le sujet), que ceux qui commencez par apprendre le fonctionnel et les formulations récursives avait tout autant de mal à se faire au style impératif et au formulation avec des boucles que l’inverse.

            • [^] # Re: MMIX ?

              Posté par  . Évalué à 1.

              Tout à fait d'accord! Quand je parlais d'Haskell et Scala, je ne pensais pas au fonctionnel en général mais aux particularités de ces deux là, même parmi les langages fonctionnels. Coté Haskell, un langage pure et non-strict c'est peut être pas le plus simple comme introduction à la programmation (même si j'adore ce langage et que programmer avec des catégories est devenue une seconde nature). Coté Scala, rien que le fait que le code d'initialisation soit mélangé avec les attributs et méthodes, c'est pratique à l'usage, mais au début ca surprends quand même. Sans parler de la richesse de leur système de types qui rend la lecture de leurs API un peu cryptique pour le non initié.

              Heureusement il y a des langages fonctionnels plus accessibles. Enseigner la programmation sur un ML me parait en revanche une bon compromis entre simplicité et ouverture vers le reste.

          • [^] # Re: MMIX ?

            Posté par  (site web personnel) . Évalué à 1. Dernière modification le 26 février 2013 à 13:00.

            Mais globalement ce qu’on peut retenir c’est aussi que je ne suis pas compétent en matière de ce qui est préférable en matière didactique. ;)

            Je proposais juste au cas où cette option n’aurait pas été considéré.

  • # Étudiant qui lève le doigt

    Posté par  (site web personnel) . Évalué à 4.

    Monsieur, à quoi ça sert d'apprendre l'assembleur ?

    • [^] # Re: Prof qui répond

      Posté par  (site web personnel) . Évalué à 10.

      Ça sert à comprendre comment fonctionne les machines sur lesquelles tu développeras peut être plus tard. Ou plus généralement à comprendre comment fonctionne un ordinateur.

      Dans des cas mineurs, tu seras peut être amené à coder en assembleur, des parties d'OS, voir des drivers, voir même autre chose.

      • [^] # Re: Prof qui répond

        Posté par  . Évalué à 1.

        Le manque des nombre flottants et des caches me fait quand même grincer des dents.
        Pour le reste 100% d'accord: voir comment ça fonctionne 'pour de vrai' aide beaucoup à comprendre les concepts de haut niveau.

        • [^] # Re: Prof qui répond

          Posté par  . Évalué à 1.

          Le manque de support pour les flottant et l'absence de cache est rédhibitoire pour une architecture moderne mais dans le cadre d'une introduction à l'assembleur, ca se tient. Cela dit, je suis d'accord que l'architecture bêta est très insuffisante pour apprendre à maîtriser les architectures modernes. Je pense que les deux approches sont complémentaire. Bêta fournit une bonne introduction qui peut servir de base à un cours plus avancé.

          • [^] # Re: Prof qui répond

            Posté par  (site web personnel) . Évalué à 2.

            Ou est-ce que tu "vois" le cache au niveau de l'assembleur ?

            "La première sécurité est la liberté"

            • [^] # Re: Prof qui répond

              Posté par  . Évalué à 2.

              Dans les instructions de load: le prefetching.

              • [^] # Re: Prof qui répond

                Posté par  (site web personnel) . Évalué à 2.

                Il y a encore des gens qui utilisent ça ? Ce n'est même pas portable dans la révision du cpu suivante. De plus, la distance optimal de prefetch soit même changer avec les fréquences du cpu et de la mémoire (trop tôt et la donnée sera viré du cache avant usage, trop tard et elle encombre l'unité de load 2 fois au lieu d'une).Le pentium 4 avait 4 instructions, les core les réduisait à 2 (de mémoire).

                Je croyais que la technique n'était plus vraiment utilisé au profit du preload.

                "La première sécurité est la liberté"

      • [^] # Re: Prof qui répond

        Posté par  . Évalué à 7.

        Ça sert à comprendre comment fonctionne les machines sur lesquelles tu développeras peut être plus tard.

        s/les machines/l'émulateur bytecode d'un type de CPU/

        Non parce que ca fait longtemps que l'assembleur n'a plus qu'un lointain rapport avec le mode de fonctionnement interne des CPU (A part en embarqué léger - genre microcontrolleur - et encore).

        Sinon le gros avantage des assembleurs sur CPU classiques (x86,x86-64, Mips, Power) c'est de voir à quel point on se fait poutrer la gueule à coup de tatanne en granit par le moindre compilateur un peu professionnel sur une architecture donnée. Je dis pas que sur un ou deux cas particuliers on va pas réussir à sortir une vectorisation ou un bypass de malade qui va permettre de grater des perfs dans une boucle un peu sensible, mais l'assembleur aujourd'hui, sur une archi générique c'est un poil surfait….

      • [^] # Re: Prof qui répond

        Posté par  . Évalué à 4.

        Je plussois.
        J'ai réellement pris goût à la programmation en faisant de l'assembleur saturn.
        Le fait de savoir que tu manipules la réalité de la machine est très instructif.
        En passant à des langages de plus haut niveau, cela permet de comprendre les effets que peuvent avoir certain choix de programmation.
        C'est une perception que je n'ai pas retrouvé chez la plupart des développeurs qui pensent que la machine comprend directement le langage et n'ont aucune idées de l'impactes de leur code sur les performances ou la mémoire.
        Bref, cela me paraît très important comme bagage technique.

    • [^] # Re: Étudiant qui lève le doigt

      Posté par  . Évalué à 9.

      Ca permet de comprendre certains concepts des langages de plus haut niveau: utilisation de la mémoire, pointeurs, pile, etc. Par exemple, comment expliquer les techniques de tail-call optimisation (je parle du cas général et pas de la transformation des appels récursifs en boucle), des trampolines et autres joyeusetés sans parler de la pile d'appel? Ou même, juste comprendre ce que sont les variables, la différence entre les locales et les globales (ou entre champs/méthodes, statiques et dynamiques). La différence entre une affectation et une copie pour de très très nombreuses structures de données.

      La liste est longue. En quelques mots, les langages de plus haut niveau restent magiques tant qu'on a pas une vision claire ce qui se passe sous le tapis.

      • [^] # Re: Étudiant qui lève le doigt

        Posté par  . Évalué à 4.

        Pour un exemple concret : depuis que j'ai fait de l'assembleur, j'ai enfin arrêté de faire des segfault au bout de 100 lignes de C ! (et ma femme est revenue, et j'ai gagné au loto ;-))

        Il y a plein de trucs qui sont « évidents » en assembleur, mais cachés dans les langages de plus haut niveau. Sauf quand on a un usage un peu pointu/astucieux/crade (suivant les goûts ;-)), auquel cas on a un bug incompréhensible, parce que, justement, le langage cache sa raison. Avoir fait de l'assembleur, ou au moins étudié la chose, nous donne au moins une chance de voir d'où vient le problème.

        Après, connaître l'assembleur seulement, ça ne sert pas à grand chose (sauf pour l'étude de l'algorithmique, ce genre de choses, qui font que Knuth a écrit MMIX de cette manière). Il faut se pencher sur le fonctionnement de la machine elle même : l'alignement de la mémoire, son organisation, les registres qui se modifient tout seuls (sur les architectures pourries traditionnelles), Les accès mémoire directs, indirects, indirectement indirects (variable, pointeur, pointeur de pointeur…)… Le fonctionnement de la pile, l'interface avec les langages de plus haut niveau…

        Ça ne m'a pas trop servit sur des langages de plus haut niveau encore, par contre… (Javascript, Python… Mouais, là, l'assembleur devient vraiment lointain).

        Enfin, je ne sais pas pour les autres langages, mais pour le C, connaître les limitations de la machine sous-jacente est un vrai bonus, même si le C est censé être « abstrait ».

  • # concrete

    Posté par  (site web personnel) . Évalué à 6.

    Pourquoi ne pas utiliser un émulateur pour une vraie machine ? Par exemple une vieille console de jeu?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: concrete

      Posté par  . Évalué à 2.

      Je dirais même plus, pourquoi utiliser un émulateur tout court !,
      c'est tellement plus ludique d'apprendre en codant du "vrai" code,

      De plus la puissance des machines actuelles est hallucinante lorsque l'on code en assembleur …, cela permets de faire des traitements sympa.

      Déjà que c'est la mode des langages interprétés …, alors de l'assembleur compilé qui tourne dans une VM, pff tout se perd !

      • [^] # Re: concrete

        Posté par  . Évalué à 1.

        Voila une idée qu'elle est bonne! Grâce à Doppio ou BicaVM, la machine virtuelle tournerait dans le navigateur et serait enfin Web 3.0 ready (parce que les applets java, non seulement c'est has been mais de moins en moins supportés (failles tout ça)).

      • [^] # Re: concrete

        Posté par  (site web personnel) . Évalué à 10.

        Quand tu va apprendre à lire à tes enfant, quel bouquin vas tu leur donner ?

        A) Apprendre à lire

        B) Sarte

        Est-ce tellement plus ludique d'apprendre à lire avec des "vrai" livre?

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: concrete

            Posté par  . Évalué à 2.

            Moui, enfin pour apprendre l'assembleur commencé par l'assembleur du x86 c'est carrément rédhibitoire.
            Le MIPS me paraîtrait beaucoup mieux indiqué pour ça, ou l'ARM si on prend en compte la facilité de trouver les machines..

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 3. Dernière modification le 26 février 2013 à 14:35.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: concrete

                Posté par  . Évalué à 2.

                Je ne vois pas ce qu'il y a de rédhibitoire d'utiliser un subset cohérent du x86.

                C'est d'avoir lu 'Henessy&Patterson Computer Architecture: A Quantitative Approach',
                ça devient rédhibitoire de pousser les gens a apprendre le x86..

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 2. Dernière modification le 26 février 2013 à 16:31.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: concrete

                    Posté par  . Évalué à 3.

                    Je parlais du fait d'enseigner l'assembleur: quand tu connais le design d'un CPU, ça ne te motive pas trop à enseigner le x86..

                    Pour ce qui est de l'utilisation, il y a quand même quelque inconvénients (moins de registres que les RISCs, jeux instructions non orthogonal, suivant le CPU certaines instructions sont micro-codée (donc lente) ou pas) mais la disponibilité et les perfs sont des avantages indiscutables.

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 2. Dernière modification le 26 février 2013 à 19:48.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: concrete

                        Posté par  (site web personnel) . Évalué à 1.

                        Aujourd'hui, le nombre de registres a bien moins d'importance que l'efficacité de la cache.

                        Ça pourrait changer.
                        La fréquence de la RAM ne cesse d'augmenter là où le processeur stagne dans le domaine. Le jour où la RAM pourra délivrer l'information en un cycle d'horloge du processeur (ce qui devrait être le cas d'ici 10 ans), les mémoires caches n'auront plus lieu d'être et disparaitront.

                        • [^] # Re: concrete

                          Posté par  . Évalué à 3.

                          Pfff, complètement faux: tu confonds le débit et la latence.
                          D'ailleurs l'augmentation du débit de la mémoire se paye souvent par une augmentation de la latence..

                      • [^] # Re: concrete

                        Posté par  (site web personnel) . Évalué à 2.

                        Le jeu d'instruction x86 est totalement bordélique et traine un historique très lourd. Il faut une sacré expertise pour trouver un sous-ensemble complet et orthogonal dans la foret des instructions disponibles.

                        On peut aussi parler de la fpu à pile, qui est une exception à elle toute seul.

                        "La première sécurité est la liberté"

                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 3.

                          Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: concrete

                            Posté par  (site web personnel) . Évalué à 4.

                            "Ben, non, pas vraiment. C'est très simple."

                            J'y crois moyen. Par exemple sur core i7, il ont réhabilité les instructions de copy de string, elles étaient déprécié au profit d'instruction SSE, puis le tout est revenu pour offrir de meilleur performance (écrire le code le plus rapide possible de copie mémoire peut vite devenir très complexe).

                            "Le FPU c'est hassebine justement… Maintenant, c'est du SSE."

                            Ce n'est plus vraiment du x86, mais plus du x86-64. De plus, quand il y a besoin de fonction précise trigonométrique, les instructions x87, sont plus rapides que leur équivalent codé en SSE (surtout sur AMD). Ce n'est pas encore complètement has-been.

                            "La première sécurité est la liberté"

                            • [^] # Commentaire supprimé

                              Posté par  . Évalué à 2.

                              Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Commentaire supprimé

                                Posté par  . Évalué à 2.

                                Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: concrete

                                Posté par  (site web personnel) . Évalué à 1.

                                dans un cas tu as : 

                                    movapd  %xmm0, %xmm3
    movsd   %xmm0, 80(%esp)
    addsd   %xmm0, %xmm3
    movsd   %xmm2, (%esp)
    movsd   %xmm3, 152(%esp)
    movsd   %xmm1, 48(%esp)
    call    _tan
    movsd   152(%esp), %xmm2
    movsd   48(%esp), %xmm1
    movsd   %xmm1, (%esp)
    fstpl   136(%esp)
    addsd   136(%esp), %xmm2
    movsd   %xmm2, 152(%esp)
    movsd   LC8, %xmm2
    mulsd   144(%esp), %xmm2
    movsd   %xmm2, 64(%esp)
    call    _cos
    ...

                                et dans l'autre tu as:

                                    fstp    %st(0)
    fstp    %st(2)
    fstpl   (%esp)
    fstpt   64(%esp)
    fstpl   96(%esp)
    fstpl   80(%esp)
    fstpt   48(%esp)
    call    _tan
    fldt    64(%esp)
    fadd    %st(0), %st
    fadd    %st(1), %st
    fstpl   136(%esp)
    fldl    160(%esp)
    fstpl   (%esp)
    fstpt   64(%esp)
    call    _cos
    ...

                                donc c'est normal que les temps soient les mêmes puisqu'elles appellent les memes fonctions. Il faut utiliser fast-math pour le forcer à choisir (et inliner) les implementations x87 ou sse.

                                • [^] # Re: concrete

                                  Posté par  (site web personnel) . Évalué à 2.

                                  ET le fait que les valeurs retournés par printf soit si différent ? cela parait louche.

                                  De plus, pour faire un vrai test, il faut 2 fichiers .c différent, sinon le compilateur peut pré-calculer beaucoup de valeur si les données d'entrée sont en dure dans le programme.

                                  "La première sécurité est la liberté"

                                  • [^] # Commentaire supprimé

                                    Posté par  . Évalué à 2.

                                    Ce commentaire a été supprimé par l’équipe de modération.

                                    • [^] # Re: concrete

                                      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 01 mars 2013 à 15:52.

                                      " donc, aucun impact."

                                      Si, tu veux benché le x87 vs le sse, et tu testes la capacité à inliner de gcc…

                                      essayes avec :
                                      -funsafe-math-optimizations

                                      "La première sécurité est la liberté"

                                      • [^] # Commentaire supprimé

                                        Posté par  . Évalué à 2.

                                        Ce commentaire a été supprimé par l’équipe de modération.

                                        • [^] # Re: concrete

                                          Posté par  (site web personnel) . Évalué à 2.

                                          Qu'est-ce qui te prouve qu'il est capable de le faire aussi dans chacun des 2 cas? rien du tout. SSE manipule les opérations de base facile à manipuler, ce n'est pas le cas des fonctions trigonométriques.

                                          "La première sécurité est la liberté"

                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à 2.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                                  • [^] # Re: concrete

                                    Posté par  (site web personnel) . Évalué à 2.

                                    le but est quand même de tester les instruction x87, que tu n'utilises pas ici.

                                    "La première sécurité est la liberté"

                                  • [^] # Re: concrete

                                    Posté par  (site web personnel) . Évalué à 4.

                                    CE ne sont pas les mêmes fonctions :/ Elles ont le même nom c'est tout.

                                    Non , vérifie, lance le test-i387 dans gdb , fais ctrl-C , disassemble, tu vas tomber dans _sin, _cos ou _tan. Ici ça me sort du code sse2, certainement parce que la libm selectionne dynamiquement le code sse2 en voyant que le cpu est sse2, independament des flags que tu as utilisé. Bref ton test ne compare pas les instructions fpsin fptan etc et leurs equivalents sse2. Il faut utiliser fast-math, ou feinter en appellant sinl ou cosl qui passent systematiquement par le x87

            • [^] # Re: concrete

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              commencé par l'assembleur du x86 c'est carrément rédhibitoire.

              De tous les assembleurs que j'ai croisés (et j'ai commencé par le sc/mp 1 ;), je reste persuadé que le plus didactique était celui du Motorola 68000. Et pour rentrer dans l'intégration hard/soft, l'idéal de l'époque était sa version 8bits (oui, oui, celle du Sinclair QL) : très facile à wrapper avec une ram statique, une 2764, un UART et quelques LEDs.

              De nos jours, on doit pouvoir retrouver ça avec la série des ATMega, cœur des désormais célèbres Arduinos, et qulques autres processeurs que je connais moins bien.

              • [^] # Re: concrete

                Posté par  (site web personnel) . Évalué à 2.

                Le msp 430 est super clean. J'ai pas franchement l'impression que cela soit le cas des AVR.

                "La première sécurité est la liberté"

                • [^] # Re: concrete

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Le msp 430 est super clean.

                  Chic, le début d'une liste :)

                  Je vais regarder de plus près son jeu d'instruction. Si tu as un lien direct vers un document adéquat, je te pertinente volontiers.

                  J'ai pas franchement l'impression que cela soit le cas des AVR.

                  C'est que j'ai peut-être l'esprit déformé par bientôt 30 ans de pratique du C, mais il y a un mapping assez 1-1 entre le C et les opcodes de ces processeurs.

                  Ensuite, regarder et comprendre comment le C passe ses paramètres lors d'un appel de fonction apprend vraiment à structurer sa pansée «assembleur», ce que j'ai découvert à la grand époque de l'Atari ST. Ensuite, je suis tombé sur un bouquin absolument géant de Len Dorfman : Object-Oriented Assembly Language (éditeur Windcrest), qui m'a appris beaucoup de choses aussi sur comment maitriser un 8088.

                  Finalement, parler de tout ça me donne bien envie de rebooter une U5 et de jouer avec un Sparc64…

                • [^] # Re: concrete

                  Posté par  . Évalué à 2.

                  Le msp 430 est super clean.

                  Pour un micro-contrôleur 16 bit, tu aurais pu préciser ça m'aurait éviter de chercher et d'avoir les pointeurs NEAR/FAR qui me reviennent à l'esprit (argh!).

                  • [^] # Re: concrete

                    Posté par  (site web personnel) . Évalué à 2.

                    Quand tu passes à 32 bits, tu augmentes encore la complexité. Ici, on parle d'élément minuscule qui ne consomme rien, et on remplacer les µp 8 bits.

                    "La première sécurité est la liberté"

                    • [^] # Re: concrete

                      Posté par  . Évalué à 2.

                      Quand tu passes à 32 bits, tu augmentes encore la complexité.

                      Euh quelle complexité? Le nombre de transistors utilisés,OK mais la complexité d'utilisation c'est plutôt l'inverse: c'est plus simple de servir d'un CPU 32 bits que d'un 8/16 bits.

                      Ici, on parle d'élément minuscule qui ne consomme rien, et on remplacer les µp 8 bits.

                      La d'accord.

                      • [^] # Re: concrete

                        Posté par  (site web personnel) . Évalué à 2.

                        En général, sur les processeurs 32 bits, toutes ce qui est initialisation, gestion mémoire est plus complexe. Mais c'est vrai qu'il s'agit plus du système autour que du cpu lui -même.

                        "La première sécurité est la liberté"

        • [^] # Re: concrete

          Posté par  (site web personnel) . Évalué à 1.

          C) La Font'n J'M

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: concrete

          Posté par  (site web personnel) . Évalué à 1.

          Ayant lu le B et l’ayant trouvé d’une affligeante naïveté, je pense que je tenterais le choix A.

        • [^] # Re: concrete

          Posté par  . Évalué à 2.

          Oui c'est vrai que c'est plus intéressant d'apprendre à programmer en OCaml, Haskel, Wiz, Promela ou Lisp sur des langages que l'on ne reverra plus jamais en milieu professionnel, qu'en C ou en Basic par exemple …

          En quoi est-ce "sale" d'apprendre à programmer sur la plateforme la plus répandue au monde ?, j'ai l'impression que c'est un prétexte de snobisme intellectuel bobo-geek !

          Oui biensur je ne parle pas de passer en mode protégé, ni d'utiliser des instructions obscures
          (les élèves motivés auront de toute manière vite fait de trouver des instructions délirantes, et de les faire partager aux autres …)

          A la limite si on souhaite rester simple, bah programmer sur du micro-controleur,

          je soutiens à 100% le fait qu'il est plus facile et intéressant d'apprendre sur des éléments concrets et réutilisables que dans d'obscures VM ou technologies non réutilisables.

          Je ne suis "que" formateur depuis 10 ans pour affirmer ça …

          Nicolas

          • [^] # Re: concrete

            Posté par  . Évalué à 1.

            Je ne suis formateur que depuis la moitié de dix ans mais je vais quand même donner mon avis.

            Premier point, l'approche entre un étudiant et une formation d'adulte n'ont pas les même objectifs. En formation, les objectifs sont précis et établis à l'avance. Quand on a des étudiants, on n'a aucune idée de ce qu'ils vont affronter et autant leurs donner une vision le plus large possible.

            Deuxième point par un exemple :
            lors de mon deuxième TP de programmation, on devait résoudre une tour d'Hanoï. TP tout simple pour nous apprendre la récursivité. Langage utilisé : scheme (qui est de ce que j'ai compris un dérivé de LISP). Il faut combien d'heures d'apprentissage pour pouvoir programmer proprement en C la résolution d'une tour d’Hanoï ?

            Troisième point, encore par l'exemple pour présenter l'idée :
            apprenons rapidement à quelqu'un à écrire un programme en C, il y a globalement deux solutions. Soit on lui impose un tas de règles complexes (il faut mettre ces lignes au début pour que ça marche, il faut mettre un return 0 à la fin du main etc.) qu'on peut lui expliquer mais dont 80% de la salle aura décroché au début de l’explication.
            Ou on le fait coder proprement et il y a un risque non négligeable pour qu'il garde de mauvaises habitudes.

            Du coup, autant le faire commencer sur un langage d'étude qui lui permettra de se consacrer à l'algo, au sens des retour, voir un peu de script avec des pipes etc. et une fois qu'il a toutes les billes et une bonne compréhension de l'ensemble, lui donner les outils "de la vraie vie" dont il saura utiliser tout les éléments.

          • [^] # Re: concrete

            Posté par  (site web personnel) . Évalué à 2.

            À mon avis, si tu formes un gars sur du OCaml et qu'il est incapable de passer au Java après, c'est que tu l'as mal formé…

    • [^] # Re: concrete

      Posté par  . Évalué à 3.

      J'y ai pensé mais trouver un compromis entre simplicité et suffisamment de ressources n'est pas si simple. Vu qu'ils ne sont qu'en deuxième année dans un cursus pas entièrement info, il me faut éviter toute complication. D'un coté il faut suffisamment de mémoire pour qu'ils n'aient pas à optimiser leur code. D'un autre, leur expliquer la programmation des sprites, des différents layers, etc prendrait trop de temps. Il faut aussi des outils multi-plateformes, idéalement installables en un clic. Ca limite quelque peu le choix.

      C'est pourquoi je suis parti sur un brave framebuffer en mode texte. Ca fait fait le boulot tout en restant très simple.

      • [^] # Re: concrete

        Posté par  . Évalué à 3.

        J'ai appris l'assembleur avec le compilateur borland de l'époque (TASM, MASM doit encore exister aussi),
        pour les TPs "ludiques" :

        interruption 21h pour l'affichage de texte (c'est simple)
        faire clignoter des leds du clavier
        le buzzer du PC
        programmation du port série

        Attention sous windows série NT (et linux) les accès aux IOs sont soumis à autorisations.
        (Cf ioperm)

      • [^] # Re: concrete

        Posté par  (site web personnel) . Évalué à 2.

        Certaines consoles ont quand même l'air assez "simple" à programmer:

        http://wiki.superfamicom.org/snes/show/Making+a+Small+Game+-+Tic-Tac-Toe

        Et puis le côté ludique motivera sans doute plus les élèves que "on va programmer un émulateur d'une machine qui n'existe pas et afficher du texte".

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: concrete

          Posté par  . Évalué à 3.

          Et puis le côté ludique motivera sans doute plus les élèves que "on va programmer un émulateur d'une machine qui n'existe pas et afficher du texte".

          Comment ca du texte n'est pas ludique? Et NetHack alors? ;)

  • # Sinon ARM c'est pas si déconnant que ça

    Posté par  (site web personnel) . Évalué à 4.

    De plus en plus d'Universités se base sur ARM pour enseigner l'assembleur (et on est pas loin de convaincre les ENSI :)), l'argument majeur étant la simplicité de l'assembleur (je renvois au commentaire sur OuiOui VS Sartre qui explique bien cet argument). J'ai moi même appris l'assembleur avec ARM, il y a quelques années déjà, et j'en ai un bon souvenir. En plus aujourd'hui ARM est une architecture réellement utilisée, ce qui donne encore plus de crédit à un tel choix.

    Bref, à voir.

    • [^] # Re: Sinon ARM c'est pas si déconnant que ça

      Posté par  (site web personnel) . Évalué à 3.

      ARM dispose maintenant d'un grand nombre de mode d'adressage qui l'éloigne du concept RISC.

      Ses derniers évolutions utilisent un jeu d'instruction avec 2 tailles d'instruction : 16 et 32 bits. Cela commence à se complexifier.

      Par ma part, j'ai vu l'assembleur sur hc11 et 68000. Je trouve que l'assembleur du msp430 de TI est extrêmement propre, c'est un microcontroleur 16/32 bits très efficace.

      "La première sécurité est la liberté"

      • [^] # Re: Sinon ARM c'est pas si déconnant que ça

        Posté par  (site web personnel) . Évalué à 3.

        qui l'éloigne du concept RISC

        Si le concept RISC n'existe plus sur 99% des processeurs de la planète (x86 et arm), est-ce bien utile de passer beaucoup de temps dessus?

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Sinon ARM c'est pas si déconnant que ça

        Posté par  . Évalué à 3.

        ARM dispose maintenant d'un grand nombre de mode d'adressage qui l'éloigne du concept RISC.

        Bof, pas tant que ça dans le RISC l'essentiel au point de vue adressage c'est d'avoir des instructions LOAD/STORE séparée des instructions arithmétiques qui ne touchent que les registres.

        Ses derniers évolutions utilisent un jeu d'instruction avec 2 tailles d'instruction : 16 et 32 bits. Cela commence à se complexifier.

        1) le MIPS a aussi une variante avec jeu d'instructions sur 16/32 bit
        2) tu retarde un peu: l'ARMv8 (64bit enfin) vient justement de laisser tomber les instructions 16bits.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.