1
00:00:00,860 --> 00:00:04,910
[Musique].

2
00:00:07,820 --> 00:00:12,638
[Musique].

3
00:00:11,119 --> 00:00:14,160
que signifient ces chiffres et ces lettres ?

4
00:00:12,638 --> 00:00:15,359
Eh bien, c'est une première version.

5
00:00:14,160 --> 00:00:17,261
les instructions doivent être saisies par code machine.

6
00:00:17,261 --> 00:00:20,559
Oh, je suis ennuyeux, ennuyeux.

7
00:00:18,879 --> 00:00:32,399
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.

8
00:00:30,879 --> 00:00:42,320
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.

9
00:00:39,679 --> 00:00:43,166
J'étais perplexe quant à la façon dont cela fonctionnait.

10
00:00:43,166 --> 00:00:44,807
c'était l'équivalent de la magie pour moi.

11
00:00:44,807 --> 00:00:52,800
plus tard, on m'a dit que ces programmes étaient écrits en langage machine, ou comme nous l'avons appelé plus tard ml.

12
00:00:50,960 --> 00:00:54,306
ce n’était pas seulement une affaire de commodore.

13
00:00:54,306 --> 00:01:00,640
en fait, avec la plupart des systèmes 8 bits, 99 % des logiciels et jeux commerciaux étaient écrits en langage machine.

14
00:00:58,960 --> 00:01:08,400
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.

15
00:01:06,719 --> 00:01:09,320
le langage machine n’était donc pas une exception.

16
00:01:09,320 --> 00:01:16,400
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.

17
00:01:15,040 --> 00:01:22,320
Je ne vais pas vous apprendre à coder un langage machine, car cela prendrait probablement environ 10 heures et serait assez sec et ennuyeux.

18
00:01:21,118 --> 00:01:27,200
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.

19
00:01:26,000 --> 00:01:32,479
et avant de vous dire ce qu'est le langage machine, je veux commencer par vous dire ce qu'il n'est pas.

20
00:01:31,040 --> 00:01:36,159
je vais commencer par vous montrer ce petit programme de démonstration que j'ai écrit en basic.

21
00:01:34,640 --> 00:01:41,759
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.

22
00:01:39,519 --> 00:01:46,159
c'est à peu près aussi optimisé que je peux le faire fonctionner ici en mode basique sur une machine à 1 mégahertz.

23
00:01:44,399 --> 00:01:54,239
à 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.

24
00:01:52,078 --> 00:02:00,343
à l'époque, nous, les gens ordinaires, pensions que cela compilerait votre programme de base en langage machine, mais ce n'est pas vraiment vrai.

25
00:02:00,343 --> 00:02:02,272
maintenant, ne vous méprenez pas.

26
00:02:02,272 --> 00:02:04,159
le logiciel n'a jamais prétendu faire cela.

27
00:02:02,799 --> 00:02:09,277
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é.

28
00:02:09,277 --> 00:02:13,084
mais il se trouve qu'il est beaucoup plus optimisé pour la vitesse.

29
00:02:13,084 --> 00:02:18,113
si vous essayez de lister un programme après l'avoir compilé, il dira simplement blitz, comme ceci.

30
00:02:18,113 --> 00:02:24,719
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.

31
00:02:22,479 --> 00:02:31,286
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.

32
00:02:31,286 --> 00:02:43,359
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.

33
00:02:41,519 --> 00:02:43,708
alors comment ça marche ?

34
00:02:43,708 --> 00:02:48,479
Eh bien, à titre d'illustration, regardons ce programme de base simple.

35
00:02:46,479 --> 00:02:50,238
voyons comment blitz l'optimiserait.

36
00:02:48,479 --> 00:02:51,327
Eh bien, pour commencer, toutes les instructions rem peuvent être éliminées.

37
00:02:51,327 --> 00:03:01,258
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.

38
00:03:01,258 --> 00:03:16,531
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.

39
00:03:16,531 --> 00:03:23,359
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.

40
00:03:21,680 --> 00:03:34,376
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.

41
00:03:34,376 --> 00:03:38,560
alors voici une autre chose qui pourrait utiliser une optimisation.

42
00:03:36,318 --> 00:03:42,983
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.

43
00:03:42,983 --> 00:03:46,696
donc un nombre comme 53280 est en fait stocké sous forme de cinq octets distincts.

44
00:03:46,696 --> 00:03:51,920
vous pouvez réellement le constater si vous regardez le programme de base dans un moniteur de langage machine.

45
00:03:50,400 --> 00:03:56,676
Eh bien, le problème est que ces nombres doivent être convertis de chaînes en nombres pendant l'exécution.

46
00:03:56,676 --> 00:04:01,297
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.

47
00:04:01,297 --> 00:04:06,414
et ce sont donc les types d'améliorations que Blitz ou des programmes similaires feraient pour accélérer vos programmes de base.

48
00:04:06,414 --> 00:04:10,560
mais ce sont toujours des programmes essentiellement basiques.

49
00:04:09,120 --> 00:04:13,820
ils sont toujours interprétés au moment de l'exécution, certainement pas en langage machine.

50
00:04:13,820 --> 00:04:16,663
mais il n’y a pas forcément de mal à cela.

51
00:04:16,663 --> 00:04:23,519
je veux dire, si vous étiez bon en programmation en base, alors cela vous donnait certainement une option pour une vitesse supplémentaire.

52
00:04:20,798 --> 00:04:24,339
alors, qu'est-ce que le langage machine ?

53
00:04:24,339 --> 00:04:27,279
Eh bien, c'est le langage natif de votre microprocesseur.

54
00:04:27,279 --> 00:04:43,554
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.

55
00:04:43,554 --> 00:04:48,000
il y a maintenant deux façons dont cela peut se produire.

56
00:04:45,360 --> 00:05:03,680
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.

57
00:05:02,079 --> 00:05:07,280
maintenant, cet interpréteur doit toujours être présent pour que votre code fonctionne.

58
00:05:05,360 --> 00:05:14,800
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.

59
00:05:12,720 --> 00:05:24,559
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.

60
00:05:22,800 --> 00:05:32,160
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.

61
00:05:30,478 --> 00:05:30,712
maintenant.

62
00:05:30,712 --> 00:05:39,680
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.

63
00:05:37,680 --> 00:05:47,839
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.

64
00:05:45,680 --> 00:05:50,959
et je comprends que ce n’est pas aussi noir et blanc.

65
00:05:48,959 --> 00:05:55,599
le problème est qu'il doit être converti en langage machine à un moment ou à un autre.

66
00:05:53,439 --> 00:05:57,199
Alors, à quoi ressemble le langage machine ?

67
00:05:55,600 --> 00:05:59,360
Eh bien, au fond, ce n’est qu’un ensemble de chiffres.

68
00:05:57,759 --> 00:06:04,400
maintenant, ce petit programme est un exemple de programme qui fait clignoter la bordure sur un commodore 128..

69
00:06:02,478 --> 00:06:08,959
le premier numéro ici est une commande ou une instruction du processeur, ou un code d'opération si vous voulez.

70
00:06:06,959 --> 00:06:12,478
il commande au processeur d'incrémenter un nombre quelque part en mémoire.

71
00:06:10,720 --> 00:06:16,000
les deux numéros suivants sont l'adresse mémoire qui doit être incrémentée.

72
00:06:14,319 --> 00:06:27,680
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.

73
00:06:26,000 --> 00:06:35,020
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.

74
00:06:35,020 --> 00:06:39,039
maintenant, si cela vous semble confus et que vous pensez :

75
00:06:36,879 --> 00:06:43,519
Comment diable quelqu'un pourrait-il écrire des programmes complexes en langage machine ?

76
00:06:40,959 --> 00:06:47,198
Eh bien, la réalité est que personne ne l’a fait, ou du moins pas depuis les années 1970.

77
00:06:45,279 --> 00:06:54,478
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.

78
00:06:53,120 --> 00:07:00,319
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.

79
00:06:58,879 --> 00:07:04,400
c'est un peu comme la différence entre la musique et la partition musicale.

80
00:07:02,560 --> 00:07:16,160
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.

81
00:07:14,478 --> 00:07:17,599
mais d'abord je veux écrire un petit programme en basic.

82
00:07:17,599 --> 00:07:23,360
maintenant, ce programme fait également clignoter la bordure, et je pense que cela aidera à illustrer quelques choses.

83
00:07:21,598 --> 00:07:29,679
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.

84
00:07:29,679 --> 00:07:32,319
maintenant, ça a l'air d'aller assez vite.

85
00:07:30,800 --> 00:07:35,439
en fait, la bordure change plus vite que l'écran n'est dessiné.

86
00:07:33,839 --> 00:07:39,112
c'est pourquoi la bordure apparaît de plusieurs couleurs à certains endroits.

87
00:07:39,112 --> 00:07:39,850
c'est donc assez rapide, non ?

88
00:07:39,850 --> 00:07:45,120
Eh bien, écrivons maintenant le même programme en langage assembleur en utilisant le moniteur intégré.

89
00:07:43,839 --> 00:07:52,570
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.

90
00:07:52,570 --> 00:07:56,372
donc ce do2o ici est exactement le même numéro que le 53280 que nous avons utilisé en basic.

91
00:07:56,372 --> 00:07:59,140
un seul est représenté en décimal et l'autre en hexadécimal.

92
00:07:59,140 --> 00:08:00,638
voir aussi ces trois chiffres ici.

93
00:08:00,638 --> 00:08:04,878
ce sont les codes machine réels qui sont stockés dans la RAM.

94
00:08:03,120 --> 00:08:07,314
ce qui se trouve à droite n'est que la forme lisible par l'homme de ce que nous appelons l'assemblage.

95
00:08:07,314 --> 00:08:07,787
de toute façon.

96
00:08:07,787 --> 00:08:17,138
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.

97
00:08:17,138 --> 00:08:22,639
donc ce programme est en fait plus simple et plus petit que le code de base que nous avons écrit.

98
00:08:20,720 --> 00:08:34,639
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.

99
00:08:32,479 --> 00:08:34,243
et voilà.

100
00:08:34,243 --> 00:08:41,003
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.

101
00:08:41,003 --> 00:08:44,647
je vais donc vous donner un autre exemple de programme.

102
00:08:44,647 --> 00:08:55,200
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.

103
00:08:51,839 --> 00:08:57,288
la mémoire de l'écran démarre à l'adresse 1024, et cela devrait le faire.

104
00:08:57,288 --> 00:09:01,518
euh, voyons combien de temps il faut pour exécuter ce code.

105
00:08:59,278 --> 00:09:02,532
ok, environ trois ou quatre secondes.

106
00:09:02,532 --> 00:09:03,891
alors, euh, ce n'est pas si mal, n'est-ce pas, ok ?

107
00:09:03,891 --> 00:09:06,439
alors euh, maintenant faisons le même code dans le moniteur.

108
00:09:06,439 --> 00:09:10,320
maintenant, ce ne sont que quelques lignes, je vais donc vous expliquer le code maintenant.

109
00:09:08,958 --> 00:09:15,439
ne vous inquiétez pas, si vous ne comprenez pas tout cela, je pense que vous en comprendrez l'essentiel.

110
00:09:12,159 --> 00:09:16,879
ldx signifie charger x avec zéro.

111
00:09:15,440 --> 00:09:19,972
cela définit simplement la valeur du registre x à zéro.

112
00:09:19,972 --> 00:09:22,000
ensuite, txa signifie transférer x vers l'accumulateur.

113
00:09:21,519 --> 00:09:29,519
et maintenant sta signifie stocker l'accumulateur à 400, qui est le début de la RAM de l'écran et de l'hexadécimal.

114
00:09:28,000 --> 00:09:37,673
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.

115
00:09:37,673 --> 00:09:46,639
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.

116
00:09:45,120 --> 00:09:50,485
maintenant que nous avons comparé, nous allons dire au processeur de se brancher, s'il n'est pas égal, de revenir à 1302.

117
00:09:50,485 --> 00:09:56,639
s'il est égal, alors rts lui dira de revenir à la base.

118
00:09:54,639 --> 00:09:56,373
alors là-haut on y va.

119
00:09:56,373 --> 00:10:00,639
c'est assez simple, exécutons le code.

120
00:09:58,720 --> 00:10:07,759
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.

121
00:10:06,399 --> 00:10:12,083
alors maintenant que vous avez vu le langage assembleur, j'aimerais vous montrer cette petite scène de Terminator.

122
00:10:12,083 --> 00:10:18,720
et ce que vous voyez ici est le langage assembleur, et plus précisément le langage assembleur 6502 d'un Apple II.

123
00:10:16,958 --> 00:10:22,720
Peu de gens aujourd’hui reconnaîtraient cela.

124
00:10:20,240 --> 00:10:25,200
alors pourquoi l'assemblage est-il tellement plus rapide que l'assemblage de base ?

125
00:10:23,679 --> 00:10:26,058
Eh bien, comme mentionné précédemment, le basique est interprété.

126
00:10:26,058 --> 00:10:33,360
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.

127
00:10:31,759 --> 00:10:38,560
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.

128
00:10:37,120 --> 00:10:43,600
maintenant, à ce stade, je pense que je devrais m'arrêter et mentionner qu'il existe plus d'un type de langage machine.

129
00:10:41,759 --> 00:10:50,079
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.

130
00:10:47,919 --> 00:10:54,639
mais le langage machine dépend beaucoup du processeur pour lequel vous codez.

131
00:10:52,399 --> 00:10:58,319
ainsi, le code écrit sur 6502, par exemple, ne fonctionnera pas sur un z80.

132
00:10:56,240 --> 00:11:07,359
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.

133
00:11:03,839 --> 00:11:09,579
le processeur 6502 possède 151 opcodes, mais ce n'est vraiment pas beaucoup en pratique.

134
00:11:09,579 --> 00:11:12,616
en fait, il vous suffit de mémoriser 56 instructions.

135
00:11:12,616 --> 00:11:25,600
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.

136
00:11:24,159 --> 00:11:30,000
comme vous pouvez le voir en regardant vers la gauche ici, les opcodes du processeur réels sont différents.

137
00:11:28,480 --> 00:11:35,838
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.

138
00:11:34,240 --> 00:11:40,308
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.

139
00:11:40,308 --> 00:11:50,240
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.

140
00:11:48,399 --> 00:11:54,000
mais le pire, c'est qu'il n'y a pas de moyen simple d'insérer une ligne de code.

141
00:11:52,078 --> 00:11:54,529
je veux dire qu'en général, vous ne pouvez qu'écraser une ligne.

142
00:11:54,529 --> 00:11:58,879
c'est là que l'utilisation d'un compilateur devient utile.

143
00:11:57,440 --> 00:12:15,278
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.

144
00:12:12,958 --> 00:12:14,755
alors comment ça marche ?

145
00:12:14,755 --> 00:12:18,959
Eh bien, voici un très court petit exemple de programme écrit dans un bloc-notes.

146
00:12:17,360 --> 00:12:23,440
maintenant, après avoir compilé le programme, je vais l'ouvrir dans le moniteur de langage machine et voir à quoi il ressemble.

147
00:12:21,919 --> 00:12:26,699
donc la première chose que je veux mentionner est que les instructions réelles sont conservées une à une.

148
00:12:26,699 --> 00:12:30,799
il n'y a absolument aucune différence ici.

149
00:12:28,958 --> 00:12:36,159
Cependant, notre étiquette conviviale, telle que screenram, a été convertie en adresse mémoire réelle pour nous.

150
00:12:34,000 --> 00:12:43,839
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.

151
00:12:42,559 --> 00:12:56,319
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.

152
00:12:55,120 --> 00:13:06,746
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.

153
00:13:06,746 --> 00:13:14,320
alors une chose que vous vous demandez peut-être est pourquoi tout dans le langage assembleur utilise l'hexadécimal.

154
00:13:12,639 --> 00:13:16,681
je veux donc expliquer quelques choses à ce sujet pour ceux qui ne le savent pas.

155
00:13:16,681 --> 00:13:22,034
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.

156
00:13:22,034 --> 00:13:30,903
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.

157
00:13:30,903 --> 00:13:35,500
donc 9a est beaucoup plus facile à lire que la forme décimale de 154.

158
00:13:35,500 --> 00:13:44,560
un exemple peut-être meilleur serait de regarder les adresses mémoire, ce que vous devez faire souvent en langage assembleur.

159
00:13:41,679 --> 00:13:50,741
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 :

160
00:13:50,741 --> 00:13:52,479
zéro à ffff.

161
00:13:51,039 --> 00:13:57,278
mais là où les choses deviennent vraiment intéressantes, c'est lorsqu'on regarde une adresse mémoire en termes d'octets.

162
00:13:55,440 --> 00:13:57,851
voici donc la même adresse en hexadécimal et en décimal.

163
00:13:57,851 --> 00:14:05,839
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.

164
00:14:04,159 --> 00:14:15,039
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.

165
00:14:15,039 --> 00:14:22,000
mais en décimal, ces deux octets sont 208 et 32, ce qui ne semble pas avoir de sens du tout.

166
00:14:20,639 --> 00:14:25,286
en fait, il faut faire quelques calculs pour voir que c'est vrai.

167
00:14:25,286 --> 00:14:33,278
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.

168
00:14:31,839 --> 00:14:40,264
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.

169
00:14:40,264 --> 00:14:45,146
c'est toute la preuve dont vous avez besoin qu'il s'agit du meilleur système pour les ordinateurs.

170
00:14:45,146 --> 00:14:48,727
désolé, e9, deux, trois, attends, attends.

171
00:14:48,480 --> 00:14:52,052
regarde, il est écrit p7.

172
00:14:48,727 --> 00:14:51,679
tu as dit e9 ?

173
00:14:52,052 --> 00:14:52,968
là tu as raison.

174
00:14:52,968 --> 00:14:56,687
une dernière chose à propos de l'hexadécimal que je voulais mentionner est la façon dont il est représenté.

175
00:14:56,687 --> 00:15:14,480
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 :

176
00:15:11,360 --> 00:15:17,199
c plus c, sharp, java, python et bien d'autres.

177
00:15:15,360 --> 00:15:18,065
les chiffres fonctionnent exactement de la même manière.

178
00:15:18,065 --> 00:15:22,240
c'est juste une manière différente de le désigner comme hexadécimal dans le compilateur.

179
00:15:20,399 --> 00:15:23,569
Le langage assembleur en soi n'est pas si difficile.

180
00:15:23,569 --> 00:15:34,275
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.

181
00:15:34,275 --> 00:15:37,759
c'est un cauchemar de travailler avec ce langage assembleur.

182
00:15:35,919 --> 00:15:53,998
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.

183
00:15:53,998 --> 00:15:59,475
alors, comment faites-vous réellement des choses comme modifier des éléments sur l'écran ou créer de la musique, par exemple ?

184
00:15:59,475 --> 00:16:04,811
Eh bien, chaque puce de l'ordinateur se présente comme une sorte de mémoire pour le processeur.

185
00:16:04,811 --> 00:16:11,596
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.

186
00:16:11,596 --> 00:16:15,661
quand ce n'est pas de la mémoire, on a tendance à les appeler registres.

187
00:16:15,661 --> 00:16:20,239
mais du point de vue du processeur, il ne peut pas faire la différence.

188
00:16:18,799 --> 00:16:30,159
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.

189
00:16:28,480 --> 00:16:35,015
En tant que programmeur, vous devez donc vous familiariser avec tous les registres de chaque puce de l'ordinateur et leur fonctionnement.

190
00:16:35,015 --> 00:16:45,519
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.

191
00:16:44,159 --> 00:17:00,240
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é.

192
00:16:58,159 --> 00:17:05,599
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.

193
00:17:03,679 --> 00:17:11,228
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.

194
00:17:11,228 --> 00:17:12,699
garde à l'esprit.

195
00:17:12,699 --> 00:17:20,720
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.

196
00:17:18,880 --> 00:17:24,558
mais c'est toujours une tâche colossale de réécrire toutes les sous-routines audio et vidéo.

197
00:17:22,959 --> 00:17:36,719
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.

198
00:17:34,798 --> 00:17:36,639
ce n'est donc pas une mince affaire.

199
00:17:36,639 --> 00:17:43,828
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.

200
00:17:43,828 --> 00:17:58,480
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.

201
00:17:56,798 --> 00:17:59,165
Le langage machine va essentiellement dans une seule direction.

202
00:17:59,165 --> 00:18:13,678
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.

203
00:18:12,000 --> 00:18:17,280
il est beaucoup plus difficile de reconvertir la symphonie en notes.

204
00:18:15,679 --> 00:18:17,576
un autre exemple serait de brouiller un œuf.

205
00:18:17,576 --> 00:18:23,599
c'est facile de le faire dans un sens, mais le déchiffrer est une autre histoire.

206
00:18:21,440 --> 00:18:27,199
Aujourd'hui, le langage assembleur est plus ou moins un art perdu.

207
00:18:24,960 --> 00:18:37,505
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.

208
00:18:37,505 --> 00:18:39,858
je veux dire, même les systèmes d'exploitation comme le noyau Linux sont écrits en C.

209
00:18:39,858 --> 00:18:45,274
le langage assembleur d'aujourd'hui n'offre donc pas vraiment beaucoup d'avantages au codeur moderne.

210
00:18:45,274 --> 00:18:58,047
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.

211
00:18:58,047 --> 00:18:59,878
ok, une dernière chose que je veux mentionner.

212
00:18:59,878 --> 00:19:08,732
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é.

213
00:19:08,328 --> 00:19:13,637
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.

214
00:19:13,637 --> 00:19:15,010
mais euh, ouais, je vais en faire un tout.

215
00:19:15,010 --> 00:19:25,919
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.

216
00:19:23,599 --> 00:19:49,439
alors de toute façon, restez à l'écoute pour ça et, comme toujours, merci de regarder [Musique].