J'ai quelques bases très faibles en programmation et il y a quelque chose que je n'ai jamais réussi à comprendre.

Lorsque l'on écrit un code (peu importe le langage) d'un programme, on utilise un compilateur pour que ce code le réécrive et le rende exploitable.
Or ce compilateur est un programme, donc la même logique s'applique. (Il a lui aussi été compilé.)

À force de remonter on arrive à quoi ? Une suite d'opération simples (OR, AND, NOR, XOR) sur des 0 et 1 ?

Deuxième question, toutes les données informatiques se réduisent à une suite de 0 et 1 (en pratique, tension nulle ou tension non nulle) et est-ce qu'on peut réduire les opérations à ces 4 opérations de bases (OR, AND, NOR, XOR) ? En gros, toutes les autres opérations ne sont que des fonctions composées de ces 4 là ?

Merci d'avance pour vos lumières.

(Edit : En fait on peut recréer les opérations avec des NAND donc on peut tout faire avec seulement des NAND ?)

Si tu veux, au début on écrivait directement en binaire, avec des câbles et des interrupteurs.
 
Le programmeur connaissait les instructions binaire que la machine attendait, donc il écrivait son programme et celui ci pouvait directement être exécuté (enfin, après l'avoir fait passer de la feuille de papier a la machine, ce qui prenait très longtemps parfois)
 
Ensuite, on a créer l'assembleur. L'assembleur est un langage très proche du langage machine, puisque pour chaque intruction en assembleur, il existe une instruction du langage machine. On peut facilement passer le l'un a l'autre, mais l'un ressemble a "MOVE 345,4(3:4)" et l'autre a "000010001011100"
 
Le premier assembleur était en fait des humains, qui faisait la traduction. Puis quelqu'un a ecrit un programme qui le faisait, le premier "Assembleur".
 
Les premiers compilateurs a avoir été écris on donc été écrit en assembleur/langage machine (en fait, c'est un peu la même chose)
 
Sauf qu'au bout d'un moment, on obtient un langage suffisamment puissant pour qu'on puisse écrire le compilateur de ce langage, dans ce langage ! Ca a été le cas du C.
 
Maintenant, les compilateurs C sont écrits en C (par exemple GCC), et on les compiles avec la version d'avant, elle même compilé avec celle d'avant, etc...
 
En effet, écrire un compilateur complet pour les langage modernes (et qui optimise les programmes) directement en assembleur est trop complexe.
 
===
 
Ensuite, si tu remonte très loin dans les détail de la machines, ca dépend. Si tu veux, par example, dans minecraft on peut construire un ordinateur avec uniquement des portes logiques XOR. Mais d'autres architectures utilisent d'autres portes logiques, donc ca depend de ta machine. Après, en réalité on utilise plus le CPU comme une machine qui sait faire des XOR, des sommes, deplacer de la mémoire, etc, sans se préoccuper de comment les électroniciens ont vraiment réaliser le bouzin...
 
Parce qu’en vrai, un ordinateur ca gère des séries de 0 et de 1, pas juste chacun d'entre eux séparé. L'unité de base des opération d'un ordinateur est appellé le Byte. De nos jours un byte est égal a un octet (8 bit, cad huit 0 ou 1) sur la 99.999% des machines, mais au début de l'informatique (et jusque dans les années 90), les bytes n'avait souvent pas la même taille entre deux machines

Euh, les CPU 8 bits, ça fait quand même qq années que c'est fini Tout comme les CPU 16 bits et 32 bits. Aujourd'hui, sur PC de moins de 5 ans, on trouve quasi que des CPU 64 bits.
 
Y'a même des registres et instructions sur ces CPU qui permettent de travailler directement sur des vecteurs de 128 ou 256 bits (registres/instructions faits, par ex, pour optimiser un algo de chiffrement style AES, ou de l'encodage/décodage de vidéo ou audio)

C'est sur, mais je voulais pas trop rentrer dans les détail pour eviter les confusions. Ensuite, la taille d'un mot a effectivement fortement augmenter et celle des adresses mais l'unité de base reste quand même l'octet.
Un CPU sait souvent adresser une partie de mot, mais en général pas moins qu'un byte.
 
Un CPU "64 bit", c'est un CPU qui a des adresses de 64 bits de long (et en vrai, de nos jours, c'est encore en dessous,  vu qu'un CPU amd64 actuel utilise en général seulement 48 bits). Ca n'as rien a voir avec la taille d'un byte.  
 
N'oublions aussi pas qu'ils n'y a pas que des x86_64 et des ARM, plein de processeurs dans l'embarqué ne sont pas "64 bits", et ne sont pas CISC (donc les fonction spéciale AES du CPU, on oublie ^^')
 
Tous n'aide pas beaucoup a répondre a la question de l'OP de toute facon

ce paquet de buzzwords mal compris

 
Ah ?

c'est peut-être plus complètement mélangé que mal compris.

Je ne sais pas par où commencer, mais rapidement, parler abstraitement d'un CPU "64 bits" n'a pas de sens. Pour x86, le passage en 64 bits était principalement motivé pour une question de taille d'adressage, mais c'est pas le cas de tous les processeurs dits 64 bits.
Aussi, le fait que certaines implémentations ne puissent pas utiliser l'intégralité de la plage ne change pas le comportement du jeu d'instructions, donc ton point sur "un CPU AMD64 actuel" n'a rien à faire ici.
Le CISC que tu balances ici n'a aucun intérêt non plus, surtout que tu viens de parler d'ARM qui est une architecture officiellement RISC mais encore une fois, ca ne les empêcherait pas de mettre une poignée d'instructions spécifique à l'encodage AES ou même des instructions spécifiques pour aider à faire tourner une VM Java si ca leur chantait.

Bref, plutôt que de partir en live sur tout un tas de concepts mal maîtrisés, ca aurait été plus sympa de parler de Machine de Turing, vu que c'est un concept très proche de ce qui intéressait notre posteur initial, à savoir jusqu'où on peut descendre en simplification pour définir un processeur ou une machine. Ensuite, les architectures se placent à différentes hauteur d'abstraction au-dessus.

En tout cas je remercie khoyo qui a parfaitement répondu à ma question.

Mais il a sauté l'étape du microcode
 
A+,