Les processeurs et tout le bataclan

Bon, voici en bon français de base, comment fonctionne dans mon imaginaire un processeur.
Pas taper, j'ai besoin de passer plein de fois sur une matière avant de la comprendre !!!

Ce machin est en fait composé de circuits, qui transforment des associations de OUI-NON en un OUI, ou un NON, suivant la forme du circuit que l'association OUI-NON emprunte.

En gros, c'est comme prendre plein de petits poids, soit noir, soit blanc, de les mettre dans un gros entonnoir, dans un ordre bien précis et un seul poids sort de l'entonnoir.  Celui-ci est soit noir, soit blanc, suivant à la fois l'entonnoir emprunté et à la fois l'ordre dans lequel sont versés les petits poids de couleurs différentes.

Jusque-là, c'est ok.
C'est pour cela qu'il y a des familles de processeurs.  Même structure d'entonnoir, même famille.

Il y a derrière ces entonnoirs, des petits circuits, qui dirigent les petits poids vers ceux-ci, dans le bon ordre et à la bonne fréquence.  

On arrive à associer les entonnoirs de manière à ce que ces derniers forment des sous-entités qui peuvent reproduire des fonctions mathématiques, de manière suffisamment approximée.

C'est une des bases du travail du compilateur.


Le versement des petits poids correspond au rythme du cristal qui met sous tension les semi-conducteurs qui composent les circuits.

Le truc, c'est le stockage des données (le petit poids qui sort de l'entonnoir et la série à verser dans l'entonnoir) dans les mémoires vives.

La puissance des processeurs dépend, du nombre de ces circuits qui reproduisent des fonctions mathématiques de base, intégrés.
La puissance de la programmation (du compilateur) , dépend de l'utilisation des espaces de mémoires vives disponibles et de la composition du processeur.
Un processeur = un (langage machine ??? )

Les programmes proprement dit utilisent la mémoire vive, voire le disque dur également et donc, peuvent entrer en compétition avec le processeur, des fois que celui-ci manque de place pour ses données de traitement.

Les programmes de haut niveau utilisent des traducteurs vers les langages bas niveau.

La traduction en langage de bas niveau est en fait une espèce de précompilation.

J'adore ton post Opposum !

Bon dans le processeur, il y a deux files de petits pois : Une pour le programme et une pour les données.

Et quand le processeur démarre, il commence toujours avec la première ligne de la file programme

Ha oui, forcément, c'est cela qui met en ordre la succession des entonnoirs, pour traiter correctement les poids.

Bon, j'ai pas encore tout compris. Il y a ces mémoires qui m'embêtent.

Merci !!!

https://web.stanford.edu/class/cs101/software-1.html

https://www.unf.edu/public/cop4610/ree/Notes/PPT/PPT8E/CH%2002%20-OS8e.pdf

https://medium.com/@akhandmishra/operating-system-process-and-process-management-108d83e8ce60

les mémoires sont des cases à petits pois avec une adresse pour chaque case.

Quand le processeur doit faire A+B : Il connait où trouver A et B (C'est un des jobs du compilateur de donner une adresse à A et à B, le processeur ne connais que des adresses pour prendre les données)

Merci ludion ^^ (encore une fois )
J'ai trouvé le point qui m'intéresse (la limite entre le hard et le soft)

@Nolimit,
oui, et elles sont allouées suivant le type de données.  
Il y a donc trois types de poids :
1. ceux liés aux itérations successives qui donnent les résultats (programme)
2. les poids des datas d'entrées (données)
3. les poids qui forment la limite entre les différents types de données

Si la composition géo de la puce n'est pas optimale, il  y a forcément une surutilisation des RAM.  Non ?

en fait pas tous à fait : Dans un ordi tous les petits pois sont identiques. Blanc ou noir. Le type des données c'est la partie programme qui gère. Mais pour un proc, tous n'est que des ensemble de bits (0 ou 1). Même le programme n'est que des groupes de 0 ou 1

Si tu veux comprendre les bases des bases il faut t’intéresser aux circuits logiques (Bon c'est du graveleux, çà parle de bit et d'algèbre de Boole). Là c'est le plus bas niveau du hard avant de rentrer dans les problèmes purement électronique.

Ben oui.
L'entonnoir, c'est les circuits logiques.
La suite d'entonnoir, c'est les 0 1 du groupe de programmation.

OK, après, je ferai un traduction en langage geek, c'est promis.
Mais là, j'ai pas encore le vocabulaire. (Mon éternel point faible, les langues étrangères)

La base des Procs, c'est de comprendre que c'est con comme un ane ! La base d'un proc ce sont les registres

Pour faire une opération tel que A+B, tu as besoin de

1 registre pour l'instruction ADDITION : C'est elle qui va configurer les portes pour faire une addition
1 registre pour copier/coller les petits pois stocker à l'adresse A (Tu verras + tard comment les petits pois stocker à l'adresse de A se retrouve dans le registre)
1 registre pour copier/coller les petits pois stocker à l'adresse B
1 registre pour stocker le résultat (quoique de mémoire j'ai vu des registre d'entrée servir pour stocker le résultat)

Oui, c'est là où j'en étais arrivée.
Comment les poids sont transportés de A (ou B) vers le registre et puis retour vers les données du programme.

Mais c'est assez secondaire.
Parce que la question est finalement, une fois que j'ai uniquement besoin d'une fonction d'intégration, + communication,
1. comment je sais que le reste du processeur est bien à l'arrêt ?
2. comment contrer le commercial qui va tenter de me vendre un autre processeur, alors que le mien avec ses 2 'exp966 autres entonnoirs, suffit très bien.

Mais, là, c'est vraiment subsidiaire.
Ici, c'est pour le fun ^^

Opossum a écrit:.....
Parce que la question est finalement, une fois que j'ai uniquement besoin d'une fonction d'intégration, + communication,
1. comment je sais que le reste du processeur est bien à l'arrêt ?
2. comment contrer le commercial qui va tenter de me vendre un autre processeur, alors que le mien avec ses 2 'exp966 autres entonnoirs, suffit très bien.

Pfuiiiiit !!!!! Là on rentre dans les architectures, les pipes, les multithread, les cachesL1 L2 L3 ou autres et tout le bordel... écoute ton portefeuille sauf si pour répondre à des besoins précis.

J'ai acheté des procs pour du simu, juste une génération de procs répondait vraiment aux programmes. Pour répondre à ta question c'est adéquation soft/hard. Mais là, je démissionne du fil ou me fais payer dans mon domaine de soft

Note : Un proc n'est jamais à l'arrêt, jamais ! Ou alors il est en veille et ne fait vraiment rien, quoique !

Ha, non, merci, ça ira. ^^
On a un consultant externe. Ce sera à lui ou un de ses collègues de trancher.
Mais j'aime bien comprendre.
Donc, j'aimerais bien savoir comment fonctionne le truc, et de manière générale, je voudrais pouvoir un minimum maîtriser ma petite boite noire d'ordi (et tous ses câbles).

Quant tu auras fini de tout piger, Opossum, publie donc ce fil sous forme de petit livre d'initiation jeunesse, parce que franchement, c'est délicieux ce fil (ton premier post, c'est à peu près ce que j'avais moi-même pigé, mais je l'aurais pas écrit de façon aussi plaisante/clair - et effectivement ça me rappelle un petit livre sur les ordis que j'ai chéri dans ma jeunesse ^^)

Pfuiiiiit ! Tu as trois ou quatre vie en parallèle de dispo pour maitriser le truc ? (car tu es surdoué... sinon c'est pas possible. Au mieux tu sais faire des bench pour checker que c'est ok. Pas plus)

Heu.  Non.  
Mais j'ai déjà compris plus ou moins comment fonctionne l'architecture d'une base de données et donc ici, c'est aussi le complément pour la construction de celle-ci.  Les exportations via les fonctions stats, ce sera un appendice, sauf erreur de ma part.
Il me faudra le module communication.  Le cryptage éventuellement, mais bof.  Ca va toucher aux réseaux, pfffff.
Après, j'ai pas besoin d'aller beaucoup plus loin.  
Sauf la question des anti-virus etc.  Mais ça, c'est pour plus tard.  ça bouge trop vite pour moi pour l'instant.

@Godzi,
Les contributeurs au fil auront droit à un exemplaire dédicacé ^^

Opossum a écrit:Bon, voici en bon français de base, comment fonctionne dans mon imaginaire un processeur.
Ce machin est en fait composé de circuits, qui transforment des associations de OUI-NON en un OUI, ou un NON, suivant la forme du circuit que l'association OUI-NON emprunte.

Heu,.....non..
Pour commencer, je n'aime pas du tout l'opposition OUI/NON....
Il y a des ZÉROS, et des UN (ou du courant et pas de courant)
Si on utilise une terminologie OUI/NON, alors qu'on va effectuer des opérations logiques dessus...ça ne va pas le faire

Opossum a écrit:
En gros, c'est comme prendre plein de petits poids, soit noir, soit blanc, de les mettre dans un gros entonnoir, dans un ordre bien précis et un seul poids sort de l'entonnoir.  Celui-ci est soit noir, soit blanc, suivant à la fois l'entonnoir emprunté et à la fois l'ordre dans lequel sont versés les petits poids de couleurs différentes.

Des poids, ou des pois ?
Et non, je n'aime pas l'idée....à la limite des pièces, qui ont deux faces, et qui peuvent être soit noires, soit blanches, sachant qu'il est possible de faire changer la couleur d'une pièce, mais seulement parmi ces deux valeurs.
Et je n'aime pas l'idée de l'entonnoir, ça fait un peu le petit poi(d)s qui va sortir c'est un peu au hasard...je préfère l'idée de tuyau, que ce soit FIFO ou LIFO, l'ordre compte.
Et le tuyau il n'est pas seul, il faut imaginer qu'il y a 8 tuyaux en parallèle...enfin 8, ou 16, ou 32, ou 64..

Opossum a écrit:
C'est pour cela qu'il y a des familles de processeurs.  Même structure d'entonnoir, même famille.

Aaarrgghhhh

Opossum a écrit:
Il y a derrière ces entonnoirs, des petits circuits, qui dirigent les petits poids vers ceux-ci, dans le bon ordre et à la bonne fréquence.  

Ça, oui...

Opossum a écrit:
On arrive à associer les entonnoirs de manière à ce que ces derniers forment des sous-entités qui peuvent reproduire des fonctions mathématiques, de manière suffisamment approximée.

Alors, NOUI.
Il faut définir ce qu'est une fonction mathématique pour commencer.
Si c'est +, -, *...il n'y a AUCUNE approximation (mais il peut y avoir des dépassement de capacités)
Ça devient plus le bordel avec /, mais aussi avec des fonctions comme SIN, COS, SQRT (Racine carée) ou LOG.
Mais ce genre de fonctions ne sont qu'un sous ensemble, très particulier de ce que peut faire un processeur.

Opossum a écrit:
C'est une des bases du travail du compilateur.

Heuuuuuuuuu, non, du tout....

Opossum a écrit:
Le versement des petits poids correspond au rythme du cristal qui met sous tension les semi-conducteurs qui composent les circuits.

Le truc, c'est le stockage des données (le petit poids qui sort de l'entonnoir et la série à verser dans l'entonnoir) dans les mémoires vives.

A expliciter, c'est pas clair

Opossum a écrit:
La puissance des processeurs dépend, du nombre de ces circuits qui reproduisent des fonctions mathématiques de base, intégrés.

Franchement, les fonctions mathématiques, dans un processeur, ou s'en tape d'une force....des fonctions logiques, oui.
Les fonctions mathématiques, ou bien on ne s'en sert pas, ou bien elles sont implémentées dans le logiciel, ou bien il y a une puce (ou une partie de la puce) spécialement dédiée à ça...le co-processeur mathématique ça s'appelle...

Opossum a écrit:
La puissance de la programmation (du compilateur) , dépend de l'utilisation des espaces de mémoires vives disponibles et de la composition du processeur.

Heuuuuuuuuuuuuuuuu
Le compilater est un programme, qui a lui même été programmé et compilé (l'œuf, la poule, toussa)...et dépend des compétences du programmeur qui l'a réalisé...

Opossum a écrit:
Un processeur = un (langage machine ??? )

Oui, un processeur va utiliser un langage machine spécifique, qui est du binaire. Pour que les humains puissent le lire plus ou moins bien (on va dire moins en fait), on parle d'assembleur

Opossum a écrit:
Les programmes proprement dit utilisent la mémoire vive, voire le disque dur également et donc, peuvent entrer en compétition avec le processeur, des fois que celui-ci manque de place pour ses données de traitement.

Non, ça ne veut rien dire.

Opossum a écrit:
Les programmes de haut niveau utilisent des traducteurs vers les langages bas niveau.

Non...
Un programme de haut niveau, ça n'existe pas....
Un langage de haut niveau, oui....
Un programme réalisé dans un langage de haut niveau, c'est une suite de TEXTE faite par un humain, qui est censé faire quelque chose.
Pour que ce TEXTE se transforme en programme, alors ce TEXTE doit soit être LU par un programme pour que l'ordinateur l'execute (cas des langages interprétés, l'exemple le plus courant est le BASIC), soit ce texte doit être transformé en programme binaire par l'intermédiaire d'un compiateur.

Opossum a écrit:
La traduction en langage de bas niveau est en fait une espèce de précompilation.

Heuuuuuuuuuuuuuuuu
Il faut expliciter ce que tu veux dire par là..

Nolimit a écrit:La base des Procs, c'est de comprendre que c'est con comme un ane ! La base d'un proc ce sont les registres

Pour faire une opération tel que A+B, tu as besoin de

1 registre pour l'instruction ADDITION : C'est elle qui va configurer les portes pour faire une addition
1 registre pour copier/coller les petits pois stocker à l'adresse A (Tu verras + tard comment les petits pois stocker à l'adresse de A se retrouve dans le registre)
1 registre pour copier/coller les petits pois stocker à l'adresse B
1 registre pour stocker le résultat (quoique de mémoire j'ai vu des registre d'entrée servir pour stocker le résultat)

Non non non non non nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooon

ça ne se passe vraiment pas du tout comme ça....

Pour espérer comprendre, il faut comprendre la notion de pile opérationnelle....pour faire ça, le mieux c'est de se payer une calculatrice HP en notation RPN (notation polonaise inversée), ou de télécharger un émulateur sur le téléphone pour comprendre la logique.

A titre personnel, j'ai droid48 (qui émule une HP48Gx) dans tous mes téléphones.

il faut comprendre qu'un processeur ne fait PAS A+B......
il fait

Va chercher A, place le à un endroit précis (qui s'appelle la pile opérationnelle)
Va chercher B, place le à un endroit précis, pile opérationnelle, on va dire "empile le"
Fait l'opération + (opération qui va faire A+B)
Et ensuite...ben prendre le résultat, et en faire ce qu'on veut, par exemple le mettre dans A, ou dans B, ou dans C

J'espère que la vidéo est plus claire



Voir de 1 minutes à 6 minutes....
Et se dire que si une calculatrice manipule des chiffres, un processeur manipule des données (adresses, valeurs), mais qu'il utilise lui aussi une pile (enfin, DES)..

Et un processeur, il est a l'arrêt quand il n'y a pas d'électricité dedans (donc quand le courant est coupé), dès qu'il est allumé, il fait quelque chose.
Même quand il ne fait RIEN, en bien, NE RIEN FAIRE, c'est une suite d'instructions logiques.

Stegos a écrit:Pour espérer comprendre, il faut comprendre la notion de pile opérationnelle....pour faire ça, le mieux c'est de se payer une calculatrice HP en notation RPN (notation polonaise inversée), ou de télécharger un émulateur sur le téléphone pour comprendre la logique.

Je me faisais remarquer au lycée avec ma HP48S quand tout le monde se baladait avec une casio ou une TI.

franchement, si je pouvais, au prochain cours j'amènerais une pomme au prof

cyranolecho a écrit:franchement, si je pouvais, au prochain cours j'amènerais une pomme au prof

Avec, ou sans cyanure ?

Pour la blague, voir la biographie de Turing....

Stegos a écrit:

Nolimit a écrit:La base des Procs, c'est de comprendre que c'est con comme un ane ! La base d'un proc ce sont les registres

Pour faire une opération tel que A+B, tu as besoin de

1 registre pour l'instruction ADDITION : C'est elle qui va configurer les portes pour faire une addition
1 registre pour copier/coller les petits pois stocker à l'adresse A (Tu verras + tard comment les petits pois stocker à l'adresse de A se retrouve dans le registre)
1 registre pour copier/coller les petits pois stocker à l'adresse B
1 registre pour stocker le résultat (quoique de mémoire j'ai vu des registre d'entrée servir pour stocker le résultat)

Non non non non non nooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooon

ça ne se passe vraiment pas du tout comme ça....

Pour espérer comprendre, il faut comprendre la notion de pile opérationnelle....pour faire ça, le mieux c'est de se payer une calculatrice HP en notation RPN (notation polonaise inversée), ou de télécharger un émulateur sur le téléphone pour comprendre la logique.

A titre personnel, j'ai droid48 (qui émule une HP48Gx) dans tous mes téléphones.

il faut comprendre qu'un processeur ne fait PAS A+B......
il fait

Va chercher A, place le à un endroit précis (qui s'appelle la pile opérationnelle)
Va chercher B, place le à un endroit précis, pile opérationnelle, on va dire "empile le"
Fait l'opération + (opération qui va faire A+B)
Et ensuite...ben prendre le résultat, et en faire ce qu'on veut, par exemple le mettre dans A, ou dans B, ou dans C

J'espère que la vidéo est plus claire



Voir de 1 minutes à 6 minutes....
Et se dire que si une calculatrice manipule des chiffres, un processeur manipule des données (adresses, valeurs), mais qu'il utilise lui aussi une pile (enfin, DES)..

Et un processeur, il est a l'arrêt quand il n'y a pas d'électricité dedans (donc quand le courant est coupé), dès qu'il est allumé, il fait quelque chose.
Même quand il ne fait RIEN, en bien, NE RIEN FAIRE, c'est une suite d'instructions logiques.

En l'occurence, ça dépend
Par exemple, si tu prends la doc des opcode x86 :
https://c9x.me/x86/html/file_module_x86_id_5.html

The destination operand can be a register or a memory location; the source operand can be an immediate, a register, or a memory location

En l'occurrence les deux sont donc possible, un add a partir de la pile, un add à partir des registres (et même d'autres possibilités en vrai), selon l'opcode que tu choisis pour faire un add (dans ce cas précis du x86, mais je suis juste allé au plus simple parce qu'on voit bien la cohabitation des deux dans ce cas précis). Bref, malgré une ou deux approximations, la version de no limit n'en est pas pour autant fausse.

Pour exemple (famille des Pentium, donc vieux, mais suffisament complexe pour vous faire comprendre que l'on ne peut pas se contenter de quelques phrases pour vous expliquer) les registres (ce qui sert en quelque sorte d'espace de travail au sein du processeur)l : http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf

et après il y à ça, si vous voulez vraiment savoir à fond (pour Intel) : https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html

Stegos, la version de NoLimit marche aussi.

@Opossum : je trouve qu'à vouloir mettre à la fois l'éléctronique (avec des notions de cristal et de transistor), au même niveau que le compilateur, le langage de programmation, etc...c'est comme si t'essayais d'appréhender d'un coup la théorie des cordes, sans avoir d'abord essayé de comprendre d'un coté la relativité générale, et de l'autre la physique quantique. Je pense que tu dois accepter de stratifier ta compréhension.
1 - c'est quoi un programme, d'un point de vue logique
2 - comment mon programme utilise mon matériel
3 - comment mon programme est compilé (mais à ce stade ça peut presque ne plus être une question)
4 - comment est foutu mon matériel.

Je pense que c'est une meilleur approche. Et donc je pense que tu devrais poser les questions dans un ordre différent. La première chose, tu devrais essayer de te regarder du code, et essayer de comprendre ce que fait ce code; dans un langage de haut niveau justement. D'un point de vue logique, sans te soucier de comment dans un premier temps. Une fois que tu auras compris ce que ça fait, même un tout petit morceau de code, tu auras le bon point d'entrée pour te poser la question de comment ça le fait. Mais peut-être l'as-tu déjà fait.
Je crois dans ce domaine aux vertus de partir de l'exemple. Ca ne permet pas une compréhension globale, mais ça permet au moins de faire les connexions élémentaires.
Donc déjà première question, as-tu déjà lu (et compris) du code? As tu déjà écrit du code?

Ce que je veux mettre en avant, pour que ce soit clair, c'est que d' ABORD tu as les données, et seulement ENSUITE tu fais quelque chose avec.

Et SELON les données, et SELON ce que tu veux faire avec, tu vas obtenir plus ou moins ce que tu espères.

Ça explique aussi que le processeur se fout allègrement de ce que représentent ces données.
Que ce soit une adresse, un pixel, un nombre, un chiffre, ou un bout de MP3..pour lui, c'est du binaire, ce qui compte c'est ce qu'on lui dit de faire avec (et ce qui explique AUSSI pas mal de bugs) si on ne maîtrise pas le casting (implicite ou non)

Stegos, c'était de la vulgarisation......

Et puis suivant le fondeur, les mécanismes sont très différents.
Je n'ai pas raison mais toi non plus

J'ai pas trop compris les petits pois, j'imagine que ça représente la présence / l'absence.
Le truc vraiment à la mode, que je vois cité un peu partout (même sur une pancarte dans le métro .. ah non, ça c'était un rêve idiot).


Je pense qu'on trouve pas mal de ressources en ligne. L'idée est de partir de fils conducteurs (conceptuels) et d'une porte nand ( not and (a,b) ). Et de construire un ordinateur, qui fait tourner le programme Tetris, à partir de cette base assez minimaliste.

---

Un sujet très connexe, c'est la thèse de Church-turing, qui montre l'équivalence de toutes les machines générales capables de faire des calculs. Il existe manifestement une propriété encore plus forte, qui est grosso l'équivalence de tous les processeurs, à constante prêt (le coût de l'émulation). Je crois que c'est Feynman qui dans son cours sur l'informatique utilise l'exemple du billards pour construire des ordinateurs (avec des boules à la place des intensités électriques). Aussi en ligne on trouve des vidéos de gens qui font des ordinateurs hydrauliques

Stegos a écrit:
il faut comprendre qu'un processeur ne fait PAS A+B......
Et un processeur, il est a l'arrêt quand il n'y a pas d'électricité dedans (donc quand le courant est coupé), dès qu'il est allumé, il fait quelque chose.
Même quand il ne fait RIEN, en bien, NE RIEN FAIRE, c'est une suite d'instructions logiques.

mais .. c'est n'importe quoi ce que tu racontes ? Où y a un sens caché ? Au mieux tu prends des cas particuliers et tu les présentes comme des vérités très générales. C'est dommage pour l'éventuel lecteur.

Stegos ne dit pas n'importe quoi, il décrit le fonctionnement intime d'un type de processeur.

Stegos a écrit:

Bon, voici en bon français de base, comment fonctionne dans mon imaginaire un processeur.
Ce machin est en fait composé de circuits, qui transforment des associations de OUI-NON en un OUI, ou un NON, suivant la forme du circuit que l'association OUI-NON emprunte.

Heu,.....non..
Pour commencer, je n'aime pas du tout l'opposition OUI/NON....
Il y a des ZÉROS, et des UN (ou du courant et pas de courant)
Si on utilise une terminologie OUI/NON, alors qu'on va effectuer des opérations logiques dessus...ça ne va pas le faire

Mais, c'est pas des opérations logiques, les opérations que font les portes XOR, NOR, et IXOR (pardon   ) ??

Stegos a écrit:

En gros, c'est comme prendre plein de petits poids, soit noir, soit blanc, de les mettre dans un gros entonnoir, dans un ordre bien précis et un seul poids sort de l'entonnoir.  Celui-ci est soit noir, soit blanc, suivant à la fois l'entonnoir emprunté et à la fois l'ordre dans lequel sont versés les petits poids de couleurs différentes.

Des poids, ou des pois ?

Des poids.  Et j'ai réfléchi.  Parce que le truc, c'est de faire passer la différence de fonction entre les 0-1 des données et les 0-1 qui créent les circuits.  A la base, ce n'est jamais que du courant (ou de l'absence de courant) dans les deux cas.

Stegos a écrit:Et non, je n'aime pas l'idée....à la limite des pièces, qui ont deux faces, et qui peuvent être soit noires, soit blanches, sachant qu'il est possible de faire changer la couleur d'une pièce, mais seulement parmi ces deux valeurs.
Et je n'aime pas l'idée de l'entonnoir, ça fait un peu le petit poi(d)s qui va sortir c'est un peu au hasard...je préfère l'idée de tuyau, que ce soit FIFO ou LIFO, l'ordre compte.
Et le tuyau il n'est pas seul, il faut imaginer qu'il y a 8 tuyaux en parallèle...enfin 8, ou 16, ou 32, ou 64..

En fait, l'image de l'entonnoir permet d'un part de prendre en compte l'idée de nombre de poids nécessaire a traitement (profondeur de la porte logique) et de différence de traitement possible.  Un entonnoir n'est pas l'autre.  Faudrait que je précise qu'un entonnoir précis, avec un ordre précis de poids donnera toujours le même résultat.  L'idée du changement de couleur me gêne par le caractère aléatoire aussi.  On est d'accord qu'il n'y a pas d'aléatoire, c'est déjà ça.

Stegos a écrit:

C'est pour cela qu'il y a des familles de processeurs.  Même structure d'entonnoir, même famille.

Aaarrgghhhh

Les architectures sont semblables quand même ?  J'ai pas bien compris le sens du mot "architecture" ?

Stegos a écrit:

Il y a derrière ces entonnoirs, des petits circuits, qui dirigent les petits poids vers ceux-ci, dans le bon ordre et à la bonne fréquence.  

Ça, oui...

Ok.

Stegos a écrit:

On arrive à associer les entonnoirs de manière à ce que ces derniers forment des sous-entités qui peuvent reproduire des fonctions mathématiques, de manière suffisamment approximée.

Alors, NOUI.
Il faut définir ce qu'est une fonction mathématique pour commencer.
Si c'est +, -, *...il n'y a AUCUNE approximation (mais il peut y avoir des dépassement de capacités)
Ça devient plus le bordel avec /, mais aussi avec des fonctions comme SIN, COS, SQRT (Racine carée) ou LOG.
Mais ce genre de fonctions ne sont qu'un sous ensemble, très particulier de ce que peut faire un processeur.

Oui, c'est l'idée.  L'approximation dépend de la fonction.  N'empêche que je n'ai toujours pas compris comment l'ordinateur a lui compris que 2+2 font 4.

Stegos a écrit:

C'est une des bases du travail du compilateur.

Heuuuuuuuuu, non, du tout....

J'ai confondu avec l'assembleur ?

Stegos a écrit:

Le versement des petits poids correspond au rythme du cristal qui met sous tension les semi-conducteurs qui composent les circuits.

Le truc, c'est le stockage des données (le petit poids qui sort de l'entonnoir et la série à verser dans l'entonnoir) dans les mémoires vives.

A expliciter, c'est pas clair

"Le versement des petits poids correspond au rythme du cristal, une fois mis sous tension les semi-conducteurs qui composent les circuits."
Mieux ?

Stegos a écrit:

La puissance des processeurs dépend, du nombre de ces circuits qui reproduisent des fonctions mathématiques de base, intégrés.

Franchement, les fonctions mathématiques, dans un processeur, ou s'en tape d'une force....des fonctions logiques, oui.
Les fonctions mathématiques, ou bien on ne s'en sert pas, ou bien elles sont implémentées dans le logiciel, ou bien il y a une puce (ou une partie de la puce) spécialement dédiée à ça...le co-processeur mathématique ça s'appelle...

ok

Stegos a écrit:

La puissance de la programmation (du compilateur) , dépend de l'utilisation des espaces de mémoires vives disponibles et de la composition du processeur.

Heuuuuuuuuuuuuuuuu
Le compilater est un programme, qui a lui même été programmé et compilé (l'œuf, la poule, toussa)...et dépend des compétences du programmeur qui l'a réalisé...

ok aussi  

Stegos a écrit:

Un processeur = un (langage machine ??? )

Oui, un processeur va utiliser un langage machine spécifique, qui est du binaire. Pour que les humains puissent le lire plus ou moins bien (on va dire moins en fait), on parle d'assembleur

Stegos a écrit:

Les programmes proprement dit utilisent la mémoire vive, voire le disque dur également et donc, peuvent entrer en compétition avec le processeur, des fois que celui-ci manque de place pour ses données de traitement.

Non, ça ne veut rien dire.  

Ha.  

Stegos a écrit:

Opossum a écrit:"]
Les programmes de haut niveau utilisent des traducteurs vers les langages bas niveau.

Non...

Là, voilà, le vocabulaire et moi...

Stegos a écrit:

Un programme de haut niveau, ça n'existe pas....
Un langage de haut niveau, oui....
Un programme réalisé dans un langage de haut niveau, c'est une suite de TEXTE faite par un humain, qui est censé faire quelque chose.
Pour que ce TEXTE se transforme en programme, alors ce TEXTE doit soit être LU par un programme pour que l'ordinateur l'execute (cas des langages interprétés, l'exemple le plus courant est le BASIC), soit ce texte doit être transformé en programme binaire par l'intermédiaire d'un compiateur.

Stegos a écrit:

La traduction en langage de bas niveau est en fait une espèce de précompilation.

Heuuuuuuuuuuuuuuuu
Il faut expliciter ce que tu veux dire par là..

Bien tu viens de le faire, en me corrigeant.  

Tout grand merci !

Le versement des petits poids correspond au rythme du cristal, une fois mis sous tension les semi-conducteurs qui composent les circuits.

Je vais juste rebondir la dessus. Tu veux prendre un raccourci trop rapide entre la génératrice de fréquence, et ce qui est fait de cette fréquence. Même avec tes petits poids, c'est vachement plus compliqué que ça. Soit tu dois oublier le cristal, soit tu dois prendre le chemin long entre le cristal est tes petits poids, soit tu dois prendre cette question à part de tes petits poids.

404 a écrit:@Opossum : je trouve qu'à vouloir mettre à la fois l'éléctronique (avec des notions de cristal et de transistor), au même niveau que le compilateur, le langage de programmation, etc...c'est comme si t'essayais d'appréhender d'un coup la théorie des cordes, sans avoir d'abord essayé de comprendre d'un coté la relativité générale, et de l'autre la physique quantique. Je pense que tu dois accepter de stratifier ta compréhension.
1 - c'est quoi un programme, d'un point de vue logique
2 - comment mon programme utilise mon matériel
3 - comment mon programme est compilé (mais à ce stade ça peut presque ne plus être une question)
4 - comment est foutu mon matériel.

Je pense que c'est une meilleur approche. Et donc je pense que tu devrais poser les questions dans un ordre différent. La première chose, tu devrais essayer de te regarder du code, et essayer de comprendre ce que fait ce code; dans un langage de haut niveau justement. D'un point de vue logique, sans te soucier de comment dans un premier temps. Une fois que tu auras compris ce que ça fait, même un tout petit morceau de code, tu auras le bon point d'entrée pour te poser la question de comment ça le fait. Mais peut-être l'as-tu déjà fait.
Je crois dans ce domaine aux vertus de partir de l'exemple. Ca ne permet pas une compréhension globale, mais ça permet au moins de faire les connexions élémentaires.
Donc déjà première question, as-tu déjà lu (et compris) du code? As tu déjà écrit du code?

Bien, si on considère que le PASCAL et le VBA sont des langages, noui.
J'ai chipoté dans des feuilles excel, j'avais ma hp48 (le truc horrible des touches qui ne s'enfoncent que si t'appuie dessus de tout ton poids), j'ai créé et chipoté dans des bases Accès.
Et j'ai ouvert une fois un programmateur python. Bon, c'est pas glorieux.

Quel chemin long ?
Celui des 4 étapes.
J'y arrive pas.... Je comprends très bien les différentes étapes (enfin, je crois). Le truc, c'est qu'elles font appel à des concepts différents au niveau même de la physique et que le passage du software au hardware, ça coince.

Noui = ? Si t'as du VBA sous les yeux t'as une idée de ce que ça fait?

Le chemin long où on vulgarise un peu moins parce que dans ton analogie, faudrait déjà multiplier des poids, puis les dupliquer, puis en diviser une partie. Et puis d'ailleurs, tes poids, faudrait en avoir plusieurs catégories en fait, pour pas se perdre quand on parle parce que tu peux pas forcément te dire qu'un poids qui passerait du coté A, pourrait aussi passer du coté B, parce que fonctionnellement c'est trop différent.

(pas taper)
Non.
L'utilisation se base sur la manipulation des types de données et le résultat apparaît, mais relativement peu modifié dans mes bases.

EDIT
ok pour distinguer les types de chemins que les poids empruntent.  Mais en eux-même, non. Cela reste des impulsions.
Les sets de poids pour les data, les sets de poids pour former les enchaînements nécessaires au calcul et le calcul proprement dit des itérations.
Les trois types n'empruntent pas les mêmes voies. (sauf erreur )

Nolimit a écrit:Stegos ne dit pas n'importe quoi, il décrit le fonctionnement intime d'un type de processeur.

heu.. je pense après lecture plus attentive, que les théories de l'informatique dont j'ai connaissance, sont mals adaptées à une participation sur ce fil. Je dois vivre dans une réalité parallèle où les microprocesseurs sont fait de portes logiques et de connectique. Où les composants d'un ordinateur utilisent des bus pour communiquer.


Dans mon monde il existe des machines virtuelles (telle la JVM java).
Il existe des langages compilés (tels rust via LLVM, ou tel C via gcc)
Il existe des langages dit "assembleurs", qui dans le passé étaient directement interprétés au niveau physique avec une certaine temporalités déterministes, mais désormais c'est plus complexes (les processeurs utilisent des microcodes et sont reprogrammables).

Mais apparemment ce monde là n'a que peu de rapport avec la discussion ici

Spoiler:

Oui, mais là, c'est mon imaginaire.  ^^
C'est dire comme je suis à l'ouest.

En gros, je vois bien que les jambes, ça sert à marcher, mais j'aimerais savoir comment la marche s'acquiert. (si li'mage n'est pas trop pourrie).


Et d'ajouter, que le premier à avoir pensé au premier entonnoir et aux poids, il s'est peut-être bien dit qu'on allait envoyer des fusées avec son brol.

Opossum a écrit:Oui, mais là, c'est mon imaginaire.  ^^
C'est dire comme je suis à l'ouest.
En gros, je vois bien que les jambes, ça sert à marcher, mais j'aimerais savoir comment la marche s'acquiert. (si li'mage n'est pas trop pourrie).
Et d'ajouter, que le premier à avoir pensé au premier entonnoir et aux poids, il s'est peut-être bien dit qu'on allait envoyer des fusées avec son brol.  

Techniquement tous les ordinateurs que je connais sont basés sur le même principe. Mais on peut utiliser d'autres phénomènes physiques que l’électricité. Je dirais que le plus proche des petits poids (pois ?), ce sont les billes. Ici un gars qui essaye de construire une fonction logique avec des billes :


Un autre exemple très classiques, se sont les redstones de minecraft, utilisés pour créer des portes logiques :


Je pense que c'est bien de comprendre déjà la logique abstraite de construction, avant de se lancer dans des métaphores compliquées.

En fait Opossum, je vais prendre les choses autrement. J'ai l'impression que ce que tu veux, c'est une "vertical slice". Et je pense que la vertical slice en métaphore, ça fonctionne pas très bien.

On va essayer....Il faut juste avant que je commence que tu préfixe chaque affirmation qui va suivre, probablement sans exception, par "ceci est un raccourci, et pour servir la vulgarisation, un peu de justesse est sacrifiée; en plus ce n'est peut-être qu'un exemple minimaliste qui sert le propos, et pas la généralité à laquelle ça pourrait ressembler".

Un programmeur C veut écrire un morceau de code qui faire calculer 2+3. Il peut écrire le code suivant.
Sémantique : le symbole "//" veut dire que tout ce qui suit sur la ligne est un pur commentaire et sera ignore par le programme.
le symbole ";" signifie "fin d'instruction".

int a = 2; //S'il te plait programme, considère une variable de type "nombre entier" qui s'appelle "a", et donne lui la valeur 2
int b = 3; //S'il te plait programme, considère une variable de type "nombre entier" qui s'appelle "b", et donne lui la valeur 3
int c = a + b; //S'il te plait programme, considère une variable de type "nombre entier" qui s'appelle "c". Calcule moi la somme des variables a+b. Puis stocke le résultat dans ma variable "c"

Il faut bien noter plusieurs chose. Déjà c'est sorti de tout contexte, ça manque un peu de sens. On va devoir faire comme si. Ensuite on ne fait rien d'autre de la valeur "c" que dire au processeur de....le stocker dans "c". Il ne faut pas extrapoler quoi que ce soit de plus que ce qui est écrit en commentaire. On n'a pas demandé grand chose de plus que ces choses abstraites. En fait si on se contentait de mettre tout ça dans un vrai environnement pour pouvoir le faire s'éxecuter, on aurait un programme qui se lançerait, et se fermerait instantanément. Il aurait calculé la somme, l'aurait gardé en "mémoire" (interne du processeur) quelques nanosecondes, et puis plus rien.

Mon programmeur, maintenant, il veut faire exécuter ça a un ordinateur. Ce code, il va l'écrire dans un fichier texte, avec tout plein de contexte autour qu'on va continuer à ignorer (et j'en profiterai même pour faire n'importe quoi avec par la suite, très probablement).
Sauf qu'un ordinateur, le texte, ça veut rien dire pour lui. C'est une suite de données qui n'a pas de sens propre. Et ce qu'on veut, en prime, c'est qu'au lieu qu'elle aie son sens propre, elle aie un sens compréhensible pour l'ordinateur. Alors on va exécuter un compilateur, qui va prendre ce fichier texte en entrée, et produire un fichier exécutable, parce que le boulot d'un compilateur c, c'est de comprendre du texte qui est structuré en langage C, ce sont des données auxquelles il sait donner du sens. Pour produire ce fichier exécutable, on va convertir les instruction C, au format texte, qu'on a vu au dessus, en des instructions qu'un processeur sait comprendre.
Mon compilateur, il va faire plusieurs choses. Dans le code c qu'on a vu, il y'a plusieurs types d'instructions différentes. le code a une structure logique et uniforme pour un humain qui va écrire ça, mais en vérité il y a deux types d'instructions différentes : des instructions destinées à ce que le compilateur comprenne le contexte (pour interdire au programmeur de faire des choses, ou pour donner un sens à une instruction qui n'en a que dans un certain contexte). Au dessus, le mot clé "int", qui dit de considérer la variable comme étant de type "nombre entier", c'est "plutôt" destiné au compilateur. Ca lui dit que le nombre 2, il faut utiliser une "case" d'une certaine taille pour le stocker. Et puis ca lui dit comment il doit effectuer l'addition (si on avait utilisé nombre à virgule flottante, il aurait du prévoir une "case" d'une taille peut-être différente, ou pas d'ailleurs; et puis il aurait du effectuer son addition d'une manière différente.). Bref, ça lui donne des indices pour comprendre le "code exécutable" qu'il doit générer en sortie.
Et puis à coté il y a le code destiné à être exécuté. "Charge la valeur 2. Charge la valeur 3. additionne les 2. Stocke le résultat".
Alors je fais cette distinction, mais attention : ces deux types d'informations servent à produire le code destiné au processeur. C'est juste que si je précise pas, tu vas te demander à un moment ce que le processeur a bien pu faire de certaines informations....alors qu'en fait c'était plutôt des méta informations que le compilateur a utilisé pour générer les bonnes informations de sortie.

Bref.

Et mon exécutable qui a été généré, ça ressemble à quoi? En fait, là, il faut que tu aies conscience que le programmeur lambda n'en a lui même pas la moindre idée.
Et je vais pas aller te l'écrire en assembleur, je vais plutôt le faire en pseudo assembleur en inventant plein de choses qu'on n'a pas dit, pour le bien de l'illustration.
Le fichier exécutable, c'est compliqué. Ca a une structure précise, qui est spécifique à ton système d'exploitation, ainsi qu'à ta fameuse "famille de processeur", bref, a plein de trucs. Mais dans tout ce bordel, tu vas trouver un ensemble de données structuré qui est "ton code exécutable". Et on va se contenter de ce morceau de l'exécutable. Celui ou se trouve ce code dont on a parlé tout à l'heure. Tu vas avoir donc une suite de...disons de valeurs numériques, qui correspondent à des instructions processeur. Et donc mon pseudo code de tout à l'heure....Je vais inventer un tas d'informations de contexte que j'ai pas donné. Je vais prétendre que je suis un compilateur, et que j'ai plein d'informations que j'ai pas montré. Et au lieu de mettre du "code machine", je vais mettre une espèce de pseudo code qui va ressembler d'un peu loin à ce qu'un processeur pourrait comprendre. Et puis je vais faire des trucs qu'un compilateur ferait certainement pas avec le code que j'ai écrit, mais je vais prétendre quand même pour le bien de ce que tu cherches à comprendre; il faut juste se dire qu'avec un code plus compliqué, un compilateur "pourrait" faire ça. Et si un compilateur faisait littéralement ce que j'écris en dessous, faudrait vraiment le jeter tout de suite et en prendre un autre.

Dans la RAM (ta mémoire vive), réserve 4 cases (qu'on va appeler octet).
Dans ces 4 octets, mets la valeur 2.
Dans la RAM, réserve encore 4 octets.
Dans ces 4 nouveaux octets, mets la valeur 3.
Prend la valeur des 4 premières cases de la RAM, et copie les dans un emplacement de 4 cases du processeur, qu'on va appeler "un registre".
Prend la valeur des 4 autre cases dont on a parlé avant, et copie les dans un second registre.
Fait l'addition entre la valeur contenue dans le premier registre et le second registre, et stocke le résultat dans un troisième registre.
Dans la RAM, réserves encore 4 octets.
Copie la valeur du troisième registre dans ce nouvel emplacement de 4 octets.

Alors...euh...je suis moi même gêné par mes approximations. Vraiment, sache que j'ai fait semblant de plein de choses, juste pour illustrer des mécanismes pour lesquels, sinon, je suis obligé de me perdre dans des détails superflus et de te faire avoir des prérequis bien plus élevés avant même de commencer à expliquer.

Maintenant, j'ai un fichier exécutable, qui, a un endroit, au milieu du bordel, contient une suite "numérique" que le processeur sait comprendre tel que décrit au dessus.

Si je veux que ça s'exécute, je vais devoir le filer à mon processeur. Bon....On va reprendre un maxi raccourci (comme si je l'avais fait qu'à chaque fois que j'ai précisé )...

Le système d'exploitation, ton Windows, ton Linux, c'est lui aussi un programme. Il va prendre le fichier exécutable sur ton disque dur, et il va le charger dans ta RAM (je m'étrangle en écrivant. C'est de la vulgarisation. C'est de la vulgarisation. Considère que ce que je dis ici est totalement faux, mais te permet d'approcher un peu mieux les interactions. C'est pas non plus totalement faux mais....grmpf...c'est de la vulgarisation ).
Ensuite il va dire à ton processeur "dans la RAM, la bas, y'a un bout de donnée que tu peux considérer comme du code exécutable. Alors tu vas aller lire le contenu de manière séquentielle, et faire ce qui t'es demandé steuplè".

Je t'ai mis un peu de disque dur, un peu de ram, un peu de processeur...
Si c'est ce genre d'explications que tu veux, si en faisant une vertical slice très très TRES TRES grossière plutôt qu'une métaphore, ça te parle, et que tu veux que j'aille dans la partie hardware, que tu veux que j'aille jusqu'au cristal, va falloir que je réfléchisse deux secondes à l'angle pour l'aborder, parce que ça devient un peu plus compliqué à formuler de manière séquentielle.

@Daurinak

En fait, j'utilise la métaphore, pour valider ma compréhension.
Si elle est pertinente, c'est que j'ai correctement compris.
Le test ultime, c'est de traduire avec les mots corrects.
 
Si je le passe, il est vérifié que j'ai bien compris.  
Là, clairement, j'ai encore du boulot.  Réciter que la liste des composants d'un pc et leurs fonctions ne m'explique rien de son fonctionnement "en vrai".  
Mais c'est sans doute trop complexe pour être appréhendé en peu de fois.  

Reste, que j'aime bien comprendre le fond des choses.
Et merci pour la vidéo de la machine de Turing.  Je la vois passer de temps en temps et trouve l'idée sympa.  Dans ce qu'elle montre du fonctionnement d'un ordi, c'est pour moi comme le principe du squelette pour le corps.

404 a écrit:En fait Opossum, je vais prendre les choses autrement. J'ai l'impression que ce que tu veux, c'est une "vertical slice". Et je pense que la vertical slice en métaphore, ça fonctionne pas très bien.

On va essayer....

Merci !!

Jusque là, tout est bon dans ma tête.

404 a écrit:
Le fichier exécutable, c'est compliqué. Ca a une structure précise, qui est spécifique à ton système d'exploitation, ainsi qu'à ta fameuse "famille de processeur", bref, a plein de trucs. Mais dans tout ce bordel, tu vas trouver un ensemble de données structuré qui est "ton code exécutable".

A la limite, le code à ce niveau, je m'en moque un peu.
C'est cette partie interface soft/hard qui m'énerve.
Les instructions processeurs qui font que les données vont aller dans les bons registres, et le transfert des résultats et l'organisation en suite ou en association des circuits du processeur pour "former la suite logique qui sera la plus représentative du code (bon, l'addition, c'est ok, mais un valeur log ou autre du genre, c'est plus chaud)".
Alors soit le compilateur il a une bibliothèque quelque part de texte tout traduit, qui se réfère à l'architecture du processeur et du reste, soit il s'appuie directement sur une architecture dédiée (le module arithmétique dont parlais Stegos).

404 a écrit:
Et on va se contenter de ce morceau de l'exécutable. Celui ou se trouve ce code dont on a parlé tout à l'heure. Tu vas avoir donc une suite de...disons de valeurs numériques, qui correspondent à des instructions processeur. Et donc mon pseudo code de tout à l'heure....Je vais inventer un tas d'informations de contexte que j'ai pas donné. Je vais prétendre que je suis un compilateur, et que j'ai plein d'informations que j'ai pas montré. Et au lieu de mettre du "code machine", je vais mettre une espèce de pseudo code qui va ressembler d'un peu loin à ce qu'un processeur pourrait comprendre. Et puis je vais faire des trucs qu'un compilateur ferait certainement pas avec le code que j'ai écrit, mais je vais prétendre quand même pour le bien de ce que tu cherches à comprendre; il faut juste se dire qu'avec un code plus compliqué, un compilateur "pourrait" faire ça. Et si un compilateur faisait littéralement ce que j'écris en dessous, faudrait vraiment le jeter tout de suite et en prendre un autre.

Dans la RAM (ta mémoire vive), réserve 4 cases (qu'on va appeler octet).
Dans ces 4 octets, mets la valeur 2.
Dans la RAM, réserve encore 4 octets.
Dans ces 4 nouveaux octets, mets la valeur 3.
Prend la valeur des 4 premières cases de la RAM, et copie les dans un emplacement de 4 cases du processeur, qu'on va appeler "un registre".
Prend la valeur des 4 autre cases dont on a parlé avant, et copie les dans un second registre.
Fait l'addition entre la valeur contenue dans le premier registre et le second registre, et stocke le résultat dans un troisième registre.
Dans la RAM, réserves encore 4 octets.
Copie la valeur du troisième registre dans ce nouvel emplacement de 4 octets.

Alors...euh...je suis moi même gêné par mes approximations. Vraiment, sache que j'ai fait semblant de plein de choses, juste pour illustrer des mécanismes pour lesquels, sinon, je suis obligé de me perdre dans des détails superflus et de te faire avoir des prérequis bien plus élevés avant même de commencer à expliquer.

Maintenant, j'ai un fichier exécutable, qui, a un endroit, au milieu du bordel, contient une suite "numérique" que le processeur sait comprendre tel que décrit au dessus.

Ha, oui, j'aurais pu aussi le dire comme cela.
Alors, en fait, les prérequis, c'est quoi ?  

404 a écrit:
Le système d'exploitation, ton Windows, ton Linux, c'est lui aussi un programme. Il va prendre le fichier exécutable sur ton disque dur, et il va le charger dans ta RAM (je m'étrangle en écrivant. C'est de la vulgarisation. C'est de la vulgarisation. Considère que ce que je dis ici est totalement faux, mais te permet d'approcher un peu mieux les interactions. C'est pas non plus totalement faux mais....grmpf...c'est de la vulgarisation ).
Ensuite il va dire à ton processeur "dans la RAM, la bas, y'a un bout de donnée que tu peux considérer comme du code exécutable. Alors tu vas aller lire le contenu de manière séquentielle, et faire ce qui t'es demandé steuplè".

Je t'ai mis un peu de disque dur, un peu de ram, un peu de processeur...
Si c'est ce genre d'explications que tu veux, si en faisant une vertical slice très très TRES TRES grossière plutôt qu'une métaphore, ça te parle, et que tu veux que j'aille dans la partie hardware, que tu veux que j'aille jusqu'au cristal, va falloir que je réfléchisse deux secondes à l'angle pour l'aborder, parce que ça devient un peu plus compliqué à formuler de manière séquentielle.

Ha ben oui, volontiers, sans vouloir abuser.  
J'aime bien comprendre quand par exemple il est dit que de toute manière un processeur deux coeurs, ça ne sert pas à grand chose....
Une vague histoire de programme qui ne savait de toute manière pas les utiliser en même temps.  Genre, l'exécutable, si j'ai bien compris.

Et, en fait, sans absolument aucune vulgarisation, cela donne quoi ?

Je précise que j'ai quand même commandé un ou deux bouquins.

Opossum a écrit:@Daurinak  Et merci pour la vidéo de la machine de Turing.  Je la vois passer de temps en temps et trouve l'idée sympa.  Dans ce qu'elle montre du fonctionnement d'un ordi, c'est pour moi comme le principe du squelette pour le corps.

Alors je n'ai pas posté de vidéo de machine de turing, ou alors à mon insu. Ce qu'on appelle "machine de Turing" (universelle) entre gens avertis est un mécanisme certes universel (qui peut simuler des ordinateurs)  mais peu adaptée aux calculs réels (très lente par nature).

ça ressemble plus à ça :

C'est basé sur la notion d'état transition, alors qu'on conçoit plus les machine de von neumann comme des fonctions booléennes. Il existe un langage de programmation très inspiré des machines de turing : brainfuck

https://fr.wikipedia.org/wiki/Brainfuck

Stegos a écrit:

cyranolecho a écrit:franchement, si je pouvais, au prochain cours j'amènerais une pomme au prof

Avec, ou sans cyanure ?

Pour la blague, voir la biographie de Turing....

C'est vraiment des enculés ceux qui (ont) persécutent les homos.

Opossum a écrit:
J'aime bien comprendre quand par exemple il est dit que de toute manière un processeur deux coeurs, ça ne sert pas à grand chose....
Une vague histoire de programme qui ne savait de toute manière pas les utiliser en même temps.  Genre, l'exécutable, si j'ai bien compris.

En informatique, il y a deux types d’énoncés. Les premiers sont les énoncés factuels, qu'on peut transformer en mécanismes. Les programmes sont fondamentalement des paramétrages de ces mécanismes. Les premiers CPUs étaient des mécanismes inscrits en dur dans la matière (le silicone). Pour notre compréhension, on organise ces mécanismes en "organes" (composants) : le disque dur, l'écran, la souris, le clavier, le cpu, la carte mère, la carte réseau, la carte son ...  Les composants utilisent des protocoles pour communiquer entre eux. Pour comprendre le hardware, il est important de comprendre ces protocoles de communications. Quand on a vu beaucoup, on se rend compte qu'ils ont tous de nombreux points communs. Certains composants suffisamment complexes et paramétrable (par des programmes) sont UNIVERSAUX. C'est à dire qu'un composant A peut en remplacer un autre B, grâce à un programme (paramètre) qui décrit comment opère B et permet de l'émuler. Les humains aussi sont capables de faire ça pour des composants très simples. Un humain peut simuler dans sa tête ou avec un crayon une unité logique d'addition. A un plus haut niveau, un humain peut aussi simuler des algorithmes (qui sont des programmes qui appellent d'autre programmes [sous programmes]) car l'humain a intégré les règles qui régissent les sous programmes. Tu peux voir l'addition (modulo) comme une forme de sous programme.  

De l'autre coté, il y a des énoncés qui sont fait uniquement pour les humains, des jugements de valeurs. Ceux là ne sont pas mécanisables. Affirmer qu'un processeur a deux cœur ne sert pas à grand chose, est un tel énoncé. C'est une vérité très relative. Dans la réalité avoir deux fois plus de main d’œuvre n'est pas toujours utile, c'est ce qui justifie (vaguement et parfois) l'affirmation. C'est comme de dire que pour visser une ampoule ça ne sert à rien d'être deux. Parce que le temps qu'on perd à décider qui fait quoi aurait suffit à une seule personne pour visser l'ampoule. A contrario s'il y a 100 ampoules à visser, être deux permet d'aller deux fois plus vite, une fois qu'on a décidé qui fait quoi.

Opossum a écrit:
Les instructions processeurs qui font que les données vont aller dans les bons registres, et le transfert des résultats et l'organisation en suite ou en association des circuits du processeur pour "former la suite logique qui sera la plus représentative du code (bon, l'addition, c'est ok, mais un valeur log ou autre du genre, c'est plus chaud)".
Alors soit le compilateur il a une bibliothèque quelque part de texte tout traduit, qui se réfère à l'architecture du processeur et du reste, soit il s'appuie directement sur une architecture dédiée (le module arithmétique dont parlais Stegos).

Si on prend l'exemple du log, tu as en gros trois façons de faire.

Normalement, le but d'un programme, c'est qu'il fasse ce qu'on lui demande de faire, aussi rapidement que possible (enfin..presque), avec une taille aussi réduite que possible (parce que plus il est gros, plus il va prendre de la place en mémoire).

La première, tu veux TOUT contrôler....et tu codes absolument TOUT dans ton programme.
Ça veut dire que tu vas chercher dans des bouquins de math comment calculer un log à la main, que tu traduis ça en code, et que tu mets ce code dans ton programme.
Ça sera rapide-ou-pas, le résultat sera juste-ou-pas..mais tu auras tout sous contrôle.

La deuxième, tu utilises un langage raisonnablement évolué, et ce langage comporte une instruction LOG (ce qui est pratique).
Dans ton programme (le tien, celui en texte), tu va dire au compilateur que tu veux utiliser la fonction log, et qu'il se demerde avec.
C'est ce que va faire le compilateur, et il va utiliser la suite d'instruction qui permet de calculer un log (qui fait partie de ce qu'il sait faire)...normalement, comme c'est une fonction standard, elle est (plus ou moins) optimisée pour la vitesse, et elle est (plus ou moins) juste.

La troisième, tu SAIS que tu ne va faire tourner ton programme QUE dans des machines qui comportent un co-processeur mathématique (maintenant, c'est courant, il y a quelques décennies, nettement moins), la tu précises dans ton programme que le logiciel VA tourner sur une telle architecture (et donc ne pourra PAS tourner sur une machine qui ne comporte pas de co.-processeur).

Une autre possibilité, dans ton programme tu gères les deux options...
Tu dis que SI la machine à un co-processeur, alors utiliser la version codée en dur (dans le silicone quoi) du calcul du log, sinon alors utiliser la version logicielle du calcul du log). Ca marchera sur toutes les machines, mais pas à la même vitesse.

Opossum a écrit:
Ha, oui, j'aurais pu aussi le dire comme cela.
Alors, en fait, les prérequis, c'est quoi ?  

Ça t'aiderait si on mettait des exemples simple de code, et leur traduction "approximative" en assembleur ?

Opossum a écrit:
J'aime bien comprendre quand par exemple il est dit que de toute manière un processeur deux coeurs, ça ne sert pas à grand chose....
Une vague histoire de programme qui ne savait de toute manière pas les utiliser en même temps.  Genre, l'exécutable, si j'ai bien compris.

Arf...dans le monde windaube, il y a un certain temps, c'était vrai...ça n'est plus le cas.
Ce qui est certain, c'est que si le programme (et le système d'exploitation EST un programme) ne prend PAS en compte les capacités du processeur, tout s’exécutera sur un seul cœur, et l'autre ne fera rien.

Dans W10, ça marche, SI les settings du BIOS sont corrects.
Sous Vista, W7, W10, tu peux aussi associer QUEL programme va tourner sur QUEL cœur (en pratique, souvent photoshop)...ça peut améliorer les choses.

Après, le fait que Windaube indique de façon "bizarre" le nombre de cœurs, et que cela ne soit pas clair dans le nom du processurs, ça n'aide pas...

i.e. certains Intel Core i7 2600 CPU sont Dual Core ou Quad Core.
D'autres Core i7 CPUs sont des  6 cœurs...

Mais avec l'hyperthreading , task manager en affiche le double..

Et le fait que certains vendeurs fournissent systématiquement des systèmes multi-cœurs, mais dont il faut acheter un code pour les activer, ça n'aide pas...

Au moins, sur Cray, c'était plus simple, il suffisait de les compter....et pour savoir si ils fonctionnaient en parallèle ou non...simplement regarder le liquide de refroidissement (ok, on pouvait AUSSI le faire par la ligne de commande...mais les thermoclines dans le liquide de refroidissement, c'était cool)

C'est un peu comme avoir une installation avec 16GB sur un Windaube 32 bits...ça ne sert pas à grand chose...
Mais les vendeurs (ni l'OS) ne le disent pas...

Windows 10 Home 32-Bit 4GB
Windows 10 Pro 32-Bit 4GB
Windows 10 Pro for Workstation 32-Bit 4GB
Windows 10 Enterprise 32-Bit 4GB
Windows 10 Education 32-Bit 4GB
------------------------
Windows 7 Starter 32-Bit 2GB
Windows 7 Home Basic 32-Bit 4GB
Windows 7 Home Basic 64-Bit 8GB
Windows 7 Home Premium 32-Bit 4GB
Windows 7 Professional 32-Bit 4GB
Windows 7 Enterprise 32-Bit 4GB
--------------------------
Windows XP Home 32-Bit 4GB
Windows XP Professional 32-Bit 4GB
Windows Vista Enterprise 32-Bit 4GB
Windows Vista Ultimate 32-Bit

En allant voir ce que "valait" mon processeur, je viens de découvrir ce que cela pouvait coûter un processeur haut de gamme, et là, je comprends qu'on puisse ce poser la question du choix aussi finement, vu que cela dépend énormément de la destination du truc.

daurinak a écrit:Mais apparemment ce monde là n'a que peu de rapport avec la discussion ici

Spoiler:

Qui appuie en réalité sur les boutons ?

Les petits lutins qui habitent dans le processeur n'existent pas, j'en suis certaine.

@Stegos, non merci pour les bouts de code.  Je suis complètement incapable de les lire.  

Edit : c'est bon.

Opossum a écrit:
Qui appuie en réalité sur les boutons ?

Le plus souvent, c'est toi. Tu appuies sur les touches de ton clavier, qui sont comme des interrupteurs. Tu appuies sur les boutons de ta souris, et de rechef. Ensuite il y a des choses plus subtiles, ton pc est relié par le wifi à internet, et les ingénieurs se sont arrangés pour qu'il vive cette expérience sous une forme qui ressemble à toi appuyant sur les touches de ton clavier : on appelle ça un protocole de communication. Souvent on se contente d'une unique touche, et on utilise les intervalles pour donner du sens à tout ça. A notre niveau humain, on connaît ça aussi, on appelle ça le langage morse. Tu as un bouton, et tu appuies dessus, et tu construits ton propos, aussi naturellement qu'avec ton clavier.



Les ordinateurs font ça à des vitesse inimaginables.
Pour distinguer la touche pressée, et économiser les fils, certains claviers vont eux aussi communiquer en morse avec le PC. Ils regardent quelle touche est pressée, et envoient un signal qui décrit son numéro, au lieu de relier directement le fil à ton pc. Cette possibilité de transmettre l'identité d'une touche parmi des centaines à l'aide d'un seul fil s'appelle la sérialisation.

La version sans aucune vulgarisation, ça tient pas dans un post, faut du code plus complet, plus compliqué, faut que tu apprennes beaucoup plus de choses sur "ce que fait un programme, comment c'est structuré, comment ça fonctionne". Et faut pas mal plus de notions. Et puis ça va te faire te poser des questions que pour l'instant tu n'as pas touché du doigt, et que tu n'as pas besoin de toucher du doigt maintenant sous peine de simplement te noyer sous encore plus de détails (je vais donc éviter de trop les énoncer tout de suite)....

Et donc...On va essayer de faire le lien avec le hard....Et alors, les raccourcis, ça va être encore pire. Je vais me permettre pas mal d'amalgames...Pareil qu'avant, considère que plein de trucs sont "un peu faux" parce que "simplifiés pour le bien de la vulgarisation", bref, transmettre l'idée plutot que le mécanisme avec une grande précision. Je vais imaginer des choses "avec des technos plus simples que ton pc", et on va construire un PC qui n'existe pas dans la vraie vie, simplement pour utiliser des versions simplifiées de la choses pour aborder les concepts, et sacrifier de la justesse des détails.

Ton processeur, pour démarrer, et surtout pour qu'il fasse des choses, il a besoin d'un métronome. Il sait faire des choses qu'à chaque clic de son métronome. Alors on lui donne un oscillateur, ou un cristal. Peu importe. Un composant électronique dont le rôle est de générer une certaine fréquence tant qu'il est sous tension.
Mais le cristal, c'est lent, en général. Et puis la fréquence donnée par le cristal, c'est pas suffisant. Si tu regardes un PC, tu vas voir des fréquences un peu partout. Par exemple, ton processeur va avoir une certaine fréquence affichée (qui va définir la vitesse d’exécution des instructions, principalement), mais ta RAM va avoir une autre fréquence affichée. Et ton cristal, une troisième.
Alors ce qu'on va faire, c'est qu'on va prendre la fréquence de ce cristal, et puis dans le processeur, on va passer dans des circuits compliqués pour augmenter cette fréquence. Ou la diminuer. Et on va dupliquer tout ça en fonction de nos besoins.
On va envoyer une certaine fréquence vers l'endroit ou le processeur va exécuter son code. Et puis une autre vers "la RAM". Bon, c'est plus compliqué...Mais c'est pour illustrer. Je vais pas le dire à chaque ligne

Tes composants, quand ils parlent ensemble, ils doivent répondre à deux questions. 1 - comment on se comprend? et 2 - est-ce qu'on est sur la même temporalité.
Donc la première question, il faut qu'ils soit d'accord sur le protocole de communication. Et la seconde, il faut être sur qu'on soit synchronisés d'une manière ou d'une autre. La synchronisation temporelle c'est important. J'avais commencé à expliquer. Mais c'est se perdre pour rien. Pour l'instant, on va juste accepter que si deux composants doivent être d'accord sur la notion de temps.
Donc comment je fais pour faire parler deux composants?
Je tire des fils entre les deux.
Comment?
Y'a plein de réponse.
Je peux imaginer que j'ai un fil sur lequel je parle, et un fil sur lequel j'écoute.
Je peux imaginer que quand je parle, j'émet régulièrement un signal de synchronisation temporelle sur mon fil d'émission. Ou alors que mes transmissions ont pas le droit de dépasser une certaine durée consécutive.
Je peux imaginer que j'ai un autre fil dédié, sur lequel je fais circuler ma référence de temps, et l'autre se cale sur ma vitesse à moi pour lire.
Ou je peux aussi imaginer que sur un même fil, je peux lire et écrire, mais on a un protocole à respecter pour pas écrire en concurrence, pour savoir comment on fait pour parler chacun son tour.
On peut aussi imaginer qu'on veut aller bien plus vite, alors j'ai pas un fil pour parler, mais 4 en parallèle. Quand je vais vouloir envoyer une donnée, au lieu d'envoyer 1, puis 0, puis 1, puis 1 (etc), je vais envoyer 1 sur le premier fil, 0 sur le second, 1 sur le troisième...et ainsi je vais (grossièrement) 4 fois plus vite.
Et puis des fois ce qui est important, c'est la résistance à la perturbation, alors je vais envoyer la même donnée sur deux fils mais en différentiel (donc inversée, si je veux envoyer un 1 logique, j'envoie 1 sur le fil A et 0 sur le fil B, en même temps, comme ça s'il y a une rayonnement qui perturbe mon signal, je peux le détecter et savoir que j'ai reçu un truc faux).
Bref...Ceci n'est pas du tout exhaustif. C'est juste pour dire....c'est compliqué, et tu peux te représenter ça comme un cas unique. Différents besoins, différentes réponses.
Ce qu'il faut donc en retenir pour l'instant, c'est que pour que le processeur parle avec le disque dur, ou avec la RAM, et transfère ses données :
1 - les deux sont d'accord sur la topologie logique des fils
2 - les deux sont d'accord sur le protocole de communication à employer pour discuter sur ces fils (leur langage a eux, si on peut dire)
3 - les deux sont d'accord sur la vitesse à laquelle les données doivent être échangées.

Maintenant qu'on est passé par ces circonvolutions....

Quand ton processeur va démarrer, il sait (parce que son électronique est foutue ainsi) qu'il va devoir aller chercher un petit morceau de code de démarrage, et (toujours parce que son électronique est foutue ainsi) il sait exactement où aller le chercher. Disons que ce bout de code, il est "à l'intérieur du processeur". Parce qu'il y a été mis à la fabrication (pour l'instant on va dire ça comme ça. Oublie pas mon disclaimer du début).
Donc il va commencer à exécuter des trucs. Et un moment, dans ces trucs qu'on lui a dit de faire, il va discuter avec le disque dur pour aller chercher un plus gros bout de code, qu'on aurait qu'à appeler "Windows" (je sais, je sais, ça veut rien dire...Mais on va le dire comme ça quand même) et le charger dans la RAM. Parce que comme ça, on va pouvoir aller exécuter plutôt ce code là.
Et donc on va envoyer une commande au disque dur, disons qu'on va lui envoyer un train de bits.
Arg il manque une circonvolution.
Pour fonctionner, l'électronique aime bien le binaire. Toi quand tu comptes t'aimes bien le décimal. Tu as le droit d'utiliser tous les chiffres de 0 à 9, et après 09, tu passes à 10. Le binaire tu as seulement le droit d'utiliser 0 et 1 pour compter. Donc après 011, tu passes à 100. Et pour pas se poser la question en termes de maths, tu peux te dire qu'il y a une dictionnaire. 11 en binaire ça veut dire 3 en décimal, et 100 ça veut dire 4.
Donc on va envoyer une suite de bits à notre disque dur. Et donc on va lui envoyer les valeurs...on va inventer un protocole, et imaginer que le disque dur il est structuré comme un livre. On va lui dire "1 puis 20", qui veut dire "commande 1, je dois aller à la page spécifiée, à savoir 20". il va me répondre 0 pour me dire ok. Et puis je vais lui dire "2 puis 5", qui veut dire "commande 2, je dois aller à la ligne spécifiée, à savoir 5". Et il va me répondre 0 pour me dire ok. Et puis la je lui demande "3 puis 100" pour qu'il comprenne "commande 3, je dois lire le nombre de lettre spécifiée, à savoir 100, et les renvoyer". Et il va me renvoyer 100 valeurs numériques.
Et donc pour être d'accord sur la base de temps, on a qu'a imaginer que pour parler à mon disque dur, à chaque fois que j'envoie un 0 ou un 1, je change la valeur de mon 3eme fil (pour qu'on soit d'accord sur le temps). Et la vitesse à laquelle je fais ça dépend d'une des fameuses fréquence que j'ai généré à partir de mon cristal.
Ces valeurs numériques, j'ai peut-être la place dans mon processeur, ou pas, mais je vais les mettre dans la RAM, alors je vais faire quelque chose de similaire avec elle, pour les envoyer la bas.

Dans l'histoire, t'as surement deux programmeurs différents.
Un qui a fait un driver. C'est à dire un bout de logiciel qui dit "je vais fournir à un autre programmeur ce qu'il faut pour qu'il puisse lire 100 lettres sans avoir à se soucier des fils. Je m'occupe de tourner les pages, placer le curseur sur la bonne lignes, et renvoyer les lettres".
Un qui fait un logiciel, dans lequel lui il sait qu'il veut lire les 100 lettres du début du chapitre 4.
Bon en fait y'en a un troisième qui a écrit un autre morceau, disons le sommaire, pour qu'on puisse trouver nos pages à partir des numéros de chapitres (le file system....Le fameux FAT32, NTFS, Ext4, etc...).

Putain j'aime pas les analogies. Ca devient vite bancal...
Et tu veux mettre beaucoup de choses en même temps, sur le même niveau.

Je vais faire le grand écart, et revenir à une préconception qui te gêne, sur laquelle Stegos est revenu déjà. Le processeur, de manière générale, il sait rien faire de compliqué. Les instructions qu'il sait exécuter sont simples. Un addition oui, un log, non. Si on veut avoir du hardware qui fait des choses compliquées, c'est en dehors du processeur. Un coprocesseur mathématique. Une carte graphique/son...

Maintenant on arrive au bout de ce que j'ai pu imaginer pour expliquer ça de manière très verticale en vulgarisant de manière "acceptable"...Va falloir que tu me dises où ces "schémas" laissent des trous dans l'image que t'avais au départ.

404 a écrit: Le processeur, de manière générale, il sait rien faire de compliqué. Les instructions qu'il sait exécuter sont simples. Un addition oui, un log, non. Si on veut avoir du hardware qui fait des choses compliquées, c'est en dehors du processeur. Un coprocesseur mathématique. Une carte graphique/son...

Pour de nombreuses choses (assimilables à des fonctions qui transforment un signal en un autre), on peut aussi utiliser un "programme" au lieu d'un coprocesseur. C'est quelque chose de fascinant, cette possibilité. Par contre pour jouer du son, il va falloir un objet physique qui en est capable (la membrane du casque ou du haut parler) et les commandes bien choisies et temporisée pour que le haut parleur restitue le bon son, avec la bonne vitesse, ce qui demande une infrastructure spéciale. Là encore on va parler de protocoles. Les protocoles sont centraux dans la communication entre composants (physiques = hardware) et dans la communication entre programmes (software) et également dans le troisième cas : hardware <--> software. Bien comprendre la nature d'un programme, demande de bien comprendre la nature d'un processeur. Mais .. est c'est ce qui est incroyable, un processeur peut en simuler un autre, et les programmes peuvent être vu comme des entités indépendantes du processeur physique et de tous les protocoles associés !!!

C'est pour cette raison que l'étude de la programmation (software) est distincte de l'étude du hardware.