[Musique].
que signifient ces chiffres et ces lettres ?
Eh bien, c'est une première version.
les instructions doivent être saisies par code machine.
Oh, je suis ennuyeux, ennuyeux.
Quand j'étais enfant dans les années 80, avec mon Commodore Vic-20 et plus tard mon C64, j'étais devenu un as de l'écriture de code en Basic, dont une grande partie était apprise en tapant d'autres programmes Basic à partir de livres et de magazines.
mais lorsque j'ai commencé à acquérir davantage de logiciels commerciaux, lorsque j'essayais de lister le programme, tout ce que je voyais était une seule ligne de base avec une commande sys et quelques chiffres.
J'étais perplexe quant à la façon dont cela fonctionnait.
c'était l'équivalent de la magie pour moi.
plus tard, on m'a dit que ces programmes étaient écrits en langage machine, ou comme nous l'avons appelé plus tard ml.
ce n’était pas seulement une affaire de commodore.
en fait, avec la plupart des systèmes 8 bits, 99 % des logiciels et jeux commerciaux étaient écrits en langage machine.
cela inclurait vos jeux préférés sur l'Atari 2600 ou le système de divertissement Nintendo, la série Apple II, etc.
le langage machine n’était donc pas une exception.
en fait, c'était la norme, et dans cet épisode, j'espère apporter un peu de lumière sur ce qu'est réellement le langage machine.
Je ne vais pas vous apprendre à coder un langage machine, car cela prendrait probablement environ 10 heures et serait assez sec et ennuyeux.
mais je dois apporter un peu de lumière sur ce qu'est réellement le langage machine par rapport aux autres langages de programmation.
et avant de vous dire ce qu'est le langage machine, je veux commencer par vous dire ce qu'il n'est pas.
je vais commencer par vous montrer ce petit programme de démonstration que j'ai écrit en basic.
en fait, je l'ai utilisé dans un épisode précédent comme référence et je pense que cela fonctionne bien ici aussi.
c'est à peu près aussi optimisé que je peux le faire fonctionner ici en mode basique sur une machine à 1 mégahertz.
à l'époque, nous avions ce programme pour le Commodore 64 appelé Blitz Basic, et je pense qu'il était également connu sous le nom d'Astro Speed.
à l'époque, nous, les gens ordinaires, pensions que cela compilerait votre programme de base en langage machine, mais ce n'est pas vraiment vrai.
maintenant, ne vous méprenez pas.
le logiciel n'a jamais prétendu faire cela.
au contraire, il prétendait convertir le code en quelque chose appelé p-code, et le p-code n'est qu'un autre langage interprété.
mais il se trouve qu'il est beaucoup plus optimisé pour la vitesse.
si vous essayez de lister un programme après l'avoir compilé, il dira simplement blitz, comme ceci.
donc le code n'est plus modifiable de manière basique, et je pense que c'est pourquoi la croyance commune était qu'il s'agissait d'un langage machine.
mais de toute façon, comme vous pouvez le voir, si vous comparez le programme original écrit en basic à celui qui a été blitzé, clairement la version blitz s'exécute beaucoup plus rapidement.
c'est encore loin d'être aussi rapide que le langage machine, et avec blitz, les résultats typiques peuvent être de deux à huit fois plus rapides, selon les instructions que vous utilisez.
alors comment ça marche ?
Eh bien, à titre d'illustration, regardons ce programme de base simple.
voyons comment blitz l'optimiserait.
Eh bien, pour commencer, toutes les instructions rem peuvent être éliminées.
je veux dire, ils ne sont là que sous forme de commentaires dans le code, mais ils prennent de la place et ralentissent légèrement l'exécution, et comme le programme ne peut plus être modifié, autant le supprimer.
la prochaine chose que nous pouvons faire est de regarder où toutes les lignes de base sont réellement stockées dans la RAM et de noter leurs adresses mémoire réelles, puis nous pouvons regarder tout ce qui pointe vers un numéro de ligne, comme un go to go sub ou même une instruction next, et déterminer vers quoi ils pointent.
normalement, cela se fait pendant l'exécution, ce qui prend du temps pour rechercher le numéro de ligne et trouver son adresse mémoire.
donc, pour accélérer les choses, vous pouvez en fait remplacer les numéros de ligne par des adresses mémoire réelles, donc aucune recherche ne sera effectuée pendant l'exécution et, bien sûr, nous n'avons plus besoin du numéro de ligne, donc ils peuvent en fait être supprimés du code complètement.
alors voici une autre chose qui pourrait utiliser une optimisation.
les nombres comme celui-ci stockés en base sont en fait stockés sous forme de caractères de texte brut, une chaîne, si vous voulez.
donc un nombre comme 53280 est en fait stocké sous forme de cinq octets distincts.
vous pouvez réellement le constater si vous regardez le programme de base dans un moniteur de langage machine.
Eh bien, le problème est que ces nombres doivent être convertis de chaînes en nombres pendant l'exécution.
donc, encore une fois, nous pouvons aller de l'avant et les convertir maintenant, et de cette façon, cela permet de gagner du temps lors de l'exécution du programme.
et ce sont donc les types d'améliorations que Blitz ou des programmes similaires feraient pour accélérer vos programmes de base.
mais ce sont toujours des programmes essentiellement basiques.
ils sont toujours interprétés au moment de l'exécution, certainement pas en langage machine.
mais il n’y a pas forcément de mal à cela.
je veux dire, si vous étiez bon en programmation en base, alors cela vous donnait certainement une option pour une vitesse supplémentaire.
alors, qu'est-ce que le langage machine ?
Eh bien, c'est le langage natif de votre microprocesseur.
c'est le seul langage qu'il connaît, et chaque logiciel que vous exécutez sur votre ordinateur - qu'il s'agisse d'un ordinateur vintage ou d'un ordinateur moderne - doit être en langage machine, sinon votre processeur ne saura pas comment l'exécuter, ce qui signifie que si vous écrivez du code dans un autre langage, il devra être converti en langage machine.
il y a maintenant deux façons dont cela peut se produire.
Des langages comme Java, Python, Ruby et Perl sont tous des langages interprétés, ce qui signifie qu'ils nécessitent un logiciel distinct appelé interpréteur, ou parfois appelé environnement d'exécution, qui examinera votre code une instruction à la fois, puis le convertira en instructions en langage machine pour votre processeur.
maintenant, cet interpréteur doit toujours être présent pour que votre code fonctionne.
Le code interprété a également tendance à être le type de code le plus lent en termes de performances, mais a également tendance à avoir la courbe d'apprentissage la plus facile.
D'un autre côté, des langages comme C plus Pascal C, Sharp Cobalt et le langage assembleur sont exécutés via un compilateur qui transforme en fait le code en langage machine de manière permanente.
maintenant, une fois ce processus terminé, vous n'avez plus besoin du compilateur pour que le programme s'exécute, même si vous pourriez en avoir besoin si jamais vous souhaitez apporter des modifications au code.
maintenant.
ces types de programmes ont tendance à avoir de bien meilleures performances que les langages interprétés mais, comme mentionné précédemment, peuvent avoir une courbe d'apprentissage un peu plus élevée.
maintenant, avant de vous précipiter dans la section commentaires pour me dire à quel point je me trompe à propos de Java ou de C-Sharp, veuillez comprendre que je fais une généralisation ici.
et je comprends que ce n’est pas aussi noir et blanc.
le problème est qu'il doit être converti en langage machine à un moment ou à un autre.
Alors, à quoi ressemble le langage machine ?
Eh bien, au fond, ce n’est qu’un ensemble de chiffres.
maintenant, ce petit programme est un exemple de programme qui fait clignoter la bordure sur un commodore 128..
le premier numéro ici est une commande ou une instruction du processeur, ou un code d'opération si vous voulez.
il commande au processeur d'incrémenter un nombre quelque part en mémoire.
les deux numéros suivants sont l'adresse mémoire qui doit être incrémentée.
le numéro suivant est une autre instruction, cette fois indiquant au processeur de sauter ou d'aller à un autre endroit de la mémoire pour continuer l'exécution, et bien sûr, les deux numéros suivant cette instruction représentent l'adresse mémoire vers laquelle il va sauter.
en fait, c'est ainsi que le codage initial était réalisé sur des ordinateurs comme l'Altair avec son panneau d'interrupteurs sur le panneau avant, ou des ordinateurs comme celui de Chem.
maintenant, si cela vous semble confus et que vous pensez :
Comment diable quelqu'un pourrait-il écrire des programmes complexes en langage machine ?
Eh bien, la réalité est que personne ne l’a fait, ou du moins pas depuis les années 1970.
et je vous ai donné cet exemple non pas pour vous effrayer, mais plutôt pour vous aider à faire la différence entre le langage machine et le langage assembleur.
ces deux termes sont souvent utilisés de manière interchangeable et bien qu'ils soient étroitement liés, ils ne sont pas exactement la même chose.
c'est un peu comme la différence entre la musique et la partition musicale.
ils sont très liés et il y a un rapport de un à un entre les notes que vous entendez et ce qui est écrit sur le papier, mais ce n'est pas exactement la même chose, et comme je ne peux pas penser à une très bonne façon de l'expliquer, j'ai pensé que la meilleure chose à faire est simplement de vous le montrer.
mais d'abord je veux écrire un petit programme en basic.
maintenant, ce programme fait également clignoter la bordure, et je pense que cela aidera à illustrer quelques choses.
il va simplement compter de 0 à 255, puis écrire ce nombre dans le registre de bordure de l'écran, puis nous allons simplement répéter cela indéfiniment.
maintenant, ça a l'air d'aller assez vite.
en fait, la bordure change plus vite que l'écran n'est dessiné.
c'est pourquoi la bordure apparaît de plusieurs couleurs à certains endroits.
c'est donc assez rapide, non ?
Eh bien, écrivons maintenant le même programme en langage assembleur en utilisant le moniteur intégré.
nous allons donc démarrer notre programme à l'emplacement mémoire 1300 hexadécimal et nous allons augmenter la valeur de couleur dans la bordure de l'écran.
donc ce do2o ici est exactement le même numéro que le 53280 que nous avons utilisé en basic.
un seul est représenté en décimal et l'autre en hexadécimal.
voir aussi ces trois chiffres ici.
ce sont les codes machine réels qui sont stockés dans la RAM.
ce qui se trouve à droite n'est que la forme lisible par l'homme de ce que nous appelons l'assemblage.
de toute façon.
notre prochaine instruction est jump, qui est similaire à l'instruction go to en basic, et nous allons sauter à 1300, ce qui nous ramène directement ici dans une boucle infinie.
donc ce programme est en fait plus simple et plus petit que le code de base que nous avons écrit.
ok, alors sortons du moniteur pour revenir à la base et je vais démarrer le code en tapant sys, qui dans commodore basic appelle un programme en langage machine, et l'adresse est 4864, ce qui est le même que 1300 hex.
et voilà.
donc, cela fonctionne si vite que la bordure change tous les quelques pixels du dessin de l'écran, ce qui donne à la chose l'apparence d'un motif étrange.
je vais donc vous donner un autre exemple de programme.
ici encore, nous allons commencer en base et ce que nous allons faire est de compter de 0 à 255 à nouveau, et nous allons afficher les 255 caractères sur l'écran.
la mémoire de l'écran démarre à l'adresse 1024, et cela devrait le faire.
euh, voyons combien de temps il faut pour exécuter ce code.
ok, environ trois ou quatre secondes.
alors, euh, ce n'est pas si mal, n'est-ce pas, ok ?
alors euh, maintenant faisons le même code dans le moniteur.
maintenant, ce ne sont que quelques lignes, je vais donc vous expliquer le code maintenant.
ne vous inquiétez pas, si vous ne comprenez pas tout cela, je pense que vous en comprendrez l'essentiel.
ldx signifie charger x avec zéro.
cela définit simplement la valeur du registre x à zéro.
ensuite, txa signifie transférer x vers l'accumulateur.
et maintenant sta signifie stocker l'accumulateur à 400, qui est le début de la RAM de l'écran et de l'hexadécimal.
la virgule x à la fin signifie simplement que nous allons ajouter la valeur de x à l'adresse avant la sauvegarde i, et x signifie augmenter x d'un, puis nous allons comparer x à zéro.
maintenant, la raison pour laquelle nous faisons zéro est que si la valeur est 255 et que vous l'augmentez de un, elle reviendra à zéro, car il s'agit d'un système à huit bits.
maintenant que nous avons comparé, nous allons dire au processeur de se brancher, s'il n'est pas égal, de revenir à 1302.
s'il est égal, alors rts lui dira de revenir à la base.
alors là-haut on y va.
c'est assez simple, exécutons le code.
comme vous pouvez le voir, c'est tellement rapide que c'est terminé avant même que je lève mon doigt de la touche retour, donc je vais vous le montrer encore une fois.
alors maintenant que vous avez vu le langage assembleur, j'aimerais vous montrer cette petite scène de Terminator.
et ce que vous voyez ici est le langage assembleur, et plus précisément le langage assembleur 6502 d'un Apple II.
Peu de gens aujourd’hui reconnaîtraient cela.
alors pourquoi l'assemblage est-il tellement plus rapide que l'assemblage de base ?
Eh bien, comme mentionné précédemment, le basique est interprété.
Ainsi, pour chaque commande de base que vous voyez ici, des centaines d'instructions en langage machine sont exécutées pour l'exécuter.
en tant que tel, un langage de programmation machine fonctionnera au moins 100 fois plus rapidement que tout ce que vous pouvez écrire en Basic.
maintenant, à ce stade, je pense que je devrais m'arrêter et mentionner qu'il existe plus d'un type de langage machine.
maintenant, lorsque vous écrivez du code, comme C ou Python, il y a de fortes chances que ce code s'exécute sur n'importe quel ordinateur avec n'importe quel processeur.
mais le langage machine dépend beaucoup du processeur pour lequel vous codez.
ainsi, le code écrit sur 6502, par exemple, ne fonctionnera pas sur un z80.
ce sont des langages très différents, mais pour les besoins de cette vidéo, je vais m'en tenir au 6502, car je pense que c'est l'un des plus simples à comprendre.
le processeur 6502 possède 151 opcodes, mais ce n'est vraiment pas beaucoup en pratique.
en fait, il vous suffit de mémoriser 56 instructions.
par exemple, si vous utilisez la commande lda, qui signifie charger un nombre dans l'accumulateur, vous pouvez lui dire de charger un nombre spécifique, comme 42, ou vous pouvez lui dire de charger le nombre à partir d'une adresse mémoire spécifique comme celle-ci.
comme vous pouvez le voir en regardant vers la gauche ici, les opcodes du processeur réels sont différents.
mais en tant qu'humain, vous n'avez pas vraiment besoin de connaître la différence, car votre assembleur se chargera de déterminer quel opcode utiliser.
maintenant, ce que je vous ai montré jusqu'à présent consiste à utiliser un moniteur de langage machine qui vous permet de regarder et de modifier le code machine.
mais vous ne voudriez pas vraiment écrire un quelconque type de code qui serait plus long que quelques lignes, car vous devriez mémoriser une tonne d'adresses mémoire pour chaque sous-routine.
mais le pire, c'est qu'il n'y a pas de moyen simple d'insérer une ligne de code.
je veux dire qu'en général, vous ne pouvez qu'écraser une ligne.
c'est là que l'utilisation d'un compilateur devient utile.
voici donc une partie de mon code source pour mon récent jeu Attack of the Petsky Robots, et, comme vous pouvez le voir, il est écrit dans un éditeur de texte, et il semble beaucoup plus convivial avec des sous-routines qui ont des noms conviviaux comme rechercher un objet ou afficher un sprite de joueur, et c'est là qu'un assembleur rend la vie tellement plus facile.
alors comment ça marche ?
Eh bien, voici un très court petit exemple de programme écrit dans un bloc-notes.
maintenant, après avoir compilé le programme, je vais l'ouvrir dans le moniteur de langage machine et voir à quoi il ressemble.
donc la première chose que je veux mentionner est que les instructions réelles sont conservées une à une.
il n'y a absolument aucune différence ici.
Cependant, notre étiquette conviviale, telle que screenram, a été convertie en adresse mémoire réelle pour nous.
de même, les étiquettes que j'ai utilisées pour la boucle ont également été converties en adresses mémoire réelles, ce qui, bien sûr, correspond à l'endroit exact du code vers lequel elles sont censées pointer.
et, bien sûr, si vous vouliez juste voir le code machine résultant lui-même, vous pourriez également le regarder, et j'espère donc que cela explique mieux la différence entre ceci, qui est du code machine ou du langage machine et ceci qui est du langage assembleur.
mais ce ne sont en réalité que deux manières différentes de voir la même chose, et même si au début certains codeurs devaient écrire des logiciels en langage machine, la grande majorité utilisait un assembleur pour écrire du code beaucoup plus lisible par l'homme.
alors une chose que vous vous demandez peut-être est pourquoi tout dans le langage assembleur utilise l'hexadécimal.
je veux donc expliquer quelques choses à ce sujet pour ceux qui ne le savent pas.
c'est un système de numérotation basé sur 16 chiffres au lieu de 10, et il ajoute simplement a, b, c, d, e, f pour les six chiffres supplémentaires.
maintenant, la raison pour laquelle cela est pratique est que lorsque vous traitez des nombres de la taille d'une bouchée, un seul chiffre hexadécimal peut représenter quatre bits de votre octet, ce qui est en fait appelé un quartet, soit dit en passant.
donc 9a est beaucoup plus facile à lire que la forme décimale de 154.
un exemple peut-être meilleur serait de regarder les adresses mémoire, ce que vous devez faire souvent en langage assembleur.
en décimal, la plage de mémoire de 64 Ko d'un processeur serait représentée de 0 à 65 535, mais en hexadécimal, c'est beaucoup plus propre :
zéro à ffff.
mais là où les choses deviennent vraiment intéressantes, c'est lorsqu'on regarde une adresse mémoire en termes d'octets.
voici donc la même adresse en hexadécimal et en décimal.
maintenant, vous pourriez reconnaître cela comme l'adresse de couleur de bordure d'un Commodore 64, pour laquelle vous pouvez utiliser une instruction poke pour modifier la couleur de la bordure.
Eh bien, en langage assembleur, cette adresse doit être représentée par exactement deux octets, et en hexadécimal, ces octets sont d0 et deux zéro, ce qui est tout à fait logique.
mais en décimal, ces deux octets sont 208 et 32, ce qui ne semble pas avoir de sens du tout.
en fait, il faut faire quelques calculs pour voir que c'est vrai.
vous devrez multiplier 208 par 256, ce qui vous donne 53248, puis ajouter votre 32 de l'octet inférieur et vous obtiendrez votre nombre final.
donc, comme vous pouvez le voir, les programmeurs trouvent beaucoup plus facile de gérer ces choses comme ça en hexadécimal et, bien sûr, s'ils utilisent du texte décimal sur ligopolis.
c'est toute la preuve dont vous avez besoin qu'il s'agit du meilleur système pour les ordinateurs.
désolé, e9, deux, trois, attends, attends.
regarde, il est écrit p7.
tu as dit e9 ?
là tu as raison.
une dernière chose à propos de l'hexadécimal que je voulais mentionner est la façon dont il est représenté.
je l'ai montré avec un signe dollar devant comme ceci, ce qui est la manière normale de l'identifier dans le langage assembleur 6502 ou Pascal, Delphi ou Fourth, mais une autre façon de le représenter est de mettre un 0x devant, comme ceci, ce qui est courant dans le langage assembleur 8088 :
c plus c, sharp, java, python et bien d'autres.
les chiffres fonctionnent exactement de la même manière.
c'est juste une manière différente de le désigner comme hexadécimal dans le compilateur.
Le langage assembleur en soi n'est pas si difficile.
en fait, il y a certaines choses qui sont en réalité plus faciles à faire en langage assembleur, comme la programmation graphique, mais il y a des compromis et certaines choses qui sont un peu pénibles, par exemple travailler avec des chaînes.
c'est un cauchemar de travailler avec ce langage assembleur.
Cependant, je pense que ce qui rend souvent le langage assembleur plus difficile, c'est le fait que vous devez savoir comment fonctionne le matériel pour lequel vous codez avec le langage assembleur, et dans l'exemple du processeur 6502, vous avez vos 56 instructions, et tout cela a plus ou moins à voir avec le déplacement des nombres dans la mémoire.
alors, comment faites-vous réellement des choses comme modifier des éléments sur l'écran ou créer de la musique, par exemple ?
Eh bien, chaque puce de l'ordinateur se présente comme une sorte de mémoire pour le processeur.
ainsi dans le c64 par exemple, la puce vidéo se présente comme 47 adresses mémoire différentes, à partir de d mille d02e.
quand ce n'est pas de la mémoire, on a tendance à les appeler registres.
mais du point de vue du processeur, il ne peut pas faire la différence.
Ainsi, lorsque nous écrivons un nombre dans le registre de couleur de bordure, par exemple, le processeur pense simplement qu'il met à jour un nombre en mémoire, mais ce qui se passe réellement, c'est qu'il met à jour un registre dans la puce vidéo.
En tant que programmeur, vous devez donc vous familiariser avec tous les registres de chaque puce de l'ordinateur et leur fonctionnement.
et, bien sûr, lorsque vous passez d'un ordinateur comme le c64 à un autre ordinateur comme l'Apple II, même s'ils utilisent le même processeur, tout le reste est complètement différent.
c'est pourquoi il peut être incroyablement difficile de porter un jeu d'une machine à une autre, et je pense que c'est pourquoi les gens sont souvent confus lorsqu'ils voient que j'ai écrit ces jeux comme Planet X3 ou Attacking Psy Robots, et ils veulent que je fasse une version pour leur ordinateur préféré.
maintenant, même en passant d'un système à l'autre qui partage le même processeur, c'est toujours une tâche assez importante.
en fait, il y a une petite équipe de gars d'Apple II qui ont travaillé pour convertir les robots Petsky sur l'Apple II et, comme vous pouvez le voir, cela fonctionne principalement maintenant.
garde à l'esprit.
L'Apple II possède le même processeur que les systèmes Commodore, donc une grande partie du code est réutilisable entre ces systèmes.
mais c'est toujours une tâche colossale de réécrire toutes les sous-routines audio et vidéo.
mais ensuite, lorsque les gens me suggèrent de faire une version de mon jeu pour les systèmes qui utilisent un processeur différent - par exemple en me demandant de faire une version Amiga ou ZX Spectrum de quelque chose comme ça - à ce stade, cela devient une réécriture complète.
ce n'est donc pas une mince affaire.
je veux dire, s'il m'a fallu un an pour écrire le jeu en premier lieu, alors il me faudrait une autre année pour réécrire pratiquement tout le jeu à partir de zéro.
et je pense que c'est là que beaucoup de gens sont gâtés par les langages de programmation modernes, car si vous écrivez quelque chose en C ou en Python, vous pouvez fondamentalement vous attendre à ce que ce même code soit probablement exécuté sur plusieurs processeurs différents sur plusieurs systèmes différents avec plusieurs configurations de mémoire différentes.
Le langage machine va essentiellement dans une seule direction.
vous pouvez compiler un programme d'un langage de niveau supérieur en langage machine ou vous pouvez écrire un programme en langage machine pour commencer si vous le souhaitez, mais vous ne pouvez pas revenir dans l'autre sens, tout comme vous pouvez convertir des notes sur une feuille de musique en un symfony.
il est beaucoup plus difficile de reconvertir la symphonie en notes.
un autre exemple serait de brouiller un œuf.
c'est facile de le faire dans un sens, mais le déchiffrer est une autre histoire.
Aujourd'hui, le langage assembleur est plus ou moins un art perdu.
les compilateurs modernes sont assez bons pour créer du code machine optimisé à partir de langages de niveau supérieur, et les ordinateurs sont également tellement rapides que toute perte de vitesse que vous pourriez avoir est pratiquement négligeable de nos jours.
je veux dire, même les systèmes d'exploitation comme le noyau Linux sont écrits en C.
le langage assembleur d'aujourd'hui n'offre donc pas vraiment beaucoup d'avantages au codeur moderne.
mais si vous voulez écrire des jeux pour des ordinateurs fabriqués dans les années 1970 ou 1980, apprendre le langage machine est pratiquement indispensable, et si vous l'apprenez, vous finirez probablement par découvrir beaucoup plus d'informations sur le fonctionnement réel des ordinateurs.
ok, une dernière chose que je veux mentionner.
si vous regardez le nouveau studio et que vous pensez, eh bien, David, ce studio a l'air assez ennuyeux comparé à l'ancien, eh bien, euh, en fait, il n'est pas encore terminé.
le problème c'est que l'ancien studio a déjà été démonté donc je n'avais pas d'endroit où filmer, donc il a fallu le faire ici.
mais euh, ouais, je vais en faire un tout.
une autre vidéo de suivi dans quelques semaines ici, espérons-le, montrant la finition de l'intérieur du studio, et cela aura l'air, espérons-le, assez différent.
alors de toute façon, restez à l'écoute pour ça et, comme toujours, merci de regarder [Musique].