Bonsoir à tous,

voila je me posais enfait des questions sur la programmation.

Enfait, ca repose un peu sur une boucle infini

Alors voila,
On a un language, par exemple le C++, et puis on a un compilateur qui transforme le code en binaire.

Mais comme fonctionne le binaire exactement?
C'est très abstrait pour moi, parceque a ce que j'en sait, c'est une suite de signale 01100101001 qui correspond à des envoies ou non de courants électriques.

Mais comment est interprété ce code ?
Ne faut t-il pas programmer quelquechose qui interprète par exemple que 1001101011 signifie 3*2 (exemple au pur hasard)
Et finalement ainsi de suite.. Ne faut il pas toujours quelque chose pour interpréter ce qu'on vient de faire? Parceque le courant életrique lui n'effectue rien.

Ce serait donc les composant électronique qui transforme les informations??

Voila, je me posais pas mal de questions la dessus, merci de m'éclaircir

Les 0 et les 1 sont lus par groupe de 8 (octet) au niveau du microprocesseur, et le microprocesseur fait correspondre une instruction à chacun de ces octets.
Après, le microprocesseur transmet des infos aux différents composants de l'ordi. Mais bon, j'y connais pas grand chose moi, mais si tu veux t'amuser à comprendre ta machine depuis les sources les plus profondes, apprend l'assembleur, là tu travailles directement avec chaque octet

La question que tu poses là ne relève plus du domaine informatique mais du domaine électronique. Si tu t'intéresses à l'élec tu peux comprendre comment ça fonctionne.

C'est encore plus bas niveau que l'assembleur puisque là il s'agit d'un agencement particulier de composants électroniques qui vont traiter le signal. Des composants y'en a des tonnes, citons par exemple les portes logiques (ET, OU, XOR, NOT etc) qui, en fonction de 1 ou plusieurs sources de courant peuvent produire un résultat.
Par exemple, la porte NOT prend en entrée un courant électrique et renvoie l'inverse de ce courant électrique. Si on lui envoie un courant, elle renvoie donc pas de courant, et inversement : si on lui envoie pas de courant, elle renvoie un courant. Bien entendu, pour fonctionner cette porte doit être alimentée (elle est branchée continuellement à une autre source électrique). Cela explique comment elle peut renvoyer un courant quand elle n'en reçoit pas.
En combinant les portes logiques, tu peux créer un agencement qui, en fonction d'une certaine entrée, effectue des actions différentes.

Typiquement, un "courant" c'est par exemple une amplitude de 5V, et pas de courant c'est 0V. Donc 5V = un 1 binaire, et 0V = un 0 binaire.


C'est un domaine à part entière (je n'en suis pas fan mais j'y ai travaillé). Le fonctionnement d'un microprocesseur est trop complexe pour que j'en fasse un résumé en un post de toute manière

Mais après pour les composantes électroniques, il faut pas les programmer pour qu'il interprète le courant??

Non, c'est un processus "physique". Ils font ça tous seuls.
Après, quand on les assemble d'une certaine manière, on peut obtenir des assemblages qui font des operations plus complexes, et au fur et à mesure que tu complexifies la chose, tu peux obtenir des circuits programmables.

Oui. Les composants électronique fonctionnent d'eux même.
On en est rendu à un stade de développement telement puissant qu'on utilise les propriété physique et chimique de tel ou tel matériaux pour qu'il transmette, isole, module ou intensifie le courant qu'il passe en lui.
Ensuite, le composant, en fonction de ce qu'il reçoit, envoit des infos par ses pattes relié à la carte mère.
Ces signaux serons à nouveau interpretté, modifié etc... jusqu'à qu'ils arrivent dans ton écran et tes bafles.
On peut remarquer que le clavier et la souris et d'autres composants informatique sont branché à l'ordi mais sont soumis à une tension perpetuel tant que l'ordi est allumé. Ce qui fait que le clavier ou la souri peut envoyer des signaux eux aussi.

Tu te demande comment un proc peut gerer tout ça ?
He bien la réponse est simple. Si tu veux prendre le schéma électrique conventionnel (les truc qu'on voit en 3e) et que tu y met celui du dernier proc, ta feuille devra faire pas moin de 3kmx3km. Oui en km, c'est énorme



Bisous, Nyu


PS: Corrigez moi si j'ai dit des conneries :s

Ouah, tout ca à l'air bien complexe,
dans tous les cas l'électronique à l'air bien intéressant..

Non

Bon moi j'ai eu l'occasion de programmer un peu sur automate programmable (API). Cela permet de comprendre un peu mieux ces histoires de portes etc, puisque le fonctionnement est le même, mais en plus gros.
En plus on travaillait dans un langage graphique assez spécial, les portes étaient représentées graphiquement, et on pouvait suivre le signal électrique sur un simulateur (sur l'outil de développement) et voir son comportement, en voyant ensuite le résultat en réel sur l'automate (une fois le programme dépoyé dans celui-ci).

Si tu as l'occasion un jour... je t'assure que j'ai trouvé ça plus intéressant que l'électronique

http://www.framasoft.net/article3077.html
http://www.framasoft.net/article3378.html

Rha, ce qui est marrant, c'est de manier les composants pour réaliser des circuits simples. Le circuit typique, c'est l'afficheur 7 segments Avec quelques transistors MOS et quelques leds, on peut faire un truc pas trop moche assez facilement

Citation : JALeX

voila je me posais enfait des questions sur la programmation.

Enfait, ca repose un peu sur une boucle infini

Tu veux dire qu'une machine est en perpétuelle activité ? Oui, on peut le voir comme ça.

Citation : JALeX

Alors voila,
On a un language, par exemple le C++, et puis on a un compilateur qui transforme le code en binaire.

Mais comme fonctionne le binaire exactement?

En fait, il faut comprendre ce qu'est un processeur. C'est en fait assez simple. C'est un ensemble de composants électroniques assez bête qui va lire de la mémoire, interpréter ce qu'il lit pour en faire des actions, principalement des lecture/ecritures en mémoire, des calculs simples, des test, des sauts.

Il y a donc 2 zones mémoire distinctes (au moins sur le plan logique)

• La mémoire programme qui contient les instructions machine
• La memoire de données qui contient les données à traiter (entrée) et traitées (sorties).

La mémoire programme contient des codes machines formés de combinaisons de 0 et de 1 et représentant des instructions, c'est à dire des ordres simples données au processeurs. Ca peut être des instructions simples (pas de paramètres) ou plus complexes (1, 2, 3... paramètres). Un programe est simplement une séquence d'instructions. Pour faciliter la programmation par un humain, au lieu d'écrire en binaire (ou octal ou hexa) ce qui serait parfaitemet illisible

on a inventé le 'langage d'assemblage' ou 'assembleur' qui résulte de l'assemblage des codes machines sous une forme plus lisible :
(le même code une fois 'assemblé')

On voit que les adresses sont identiques, mais que des groupes de séquence d'octets ont été formés, et que celle-ci correspondent à des instructions bien précises.

Par exemple

Signifie "Jump if Not Zero at the 010C address"

Il s'agit ici de code machine PC (intel x86). Détails dans la doc Intel.

Je n'entre pas plus dans les détails...

Citation : JALeX

C'est très abstrait pour moi, parceque a ce que j'en sait, c'est une suite de signale 01100101001 qui correspond à des envoies ou non de courants électriques.

Mais comment est interprété ce code ?
Ne faut t-il pas programmer quelquechose qui interprète par exemple que 1001101011 signifie 3*2 (exemple au pur hasard)
Et finalement ainsi de suite.. Ne faut il pas toujours quelque chose pour interpréter ce qu'on vient de faire? Parceque le courant életrique lui n'effectue rien.

Ce serait donc les composant électronique qui transforme les informations??

Voila, je me posais pas mal de questions la dessus, merci de m'éclaircir

Ce qui interprète les instructions, ce sont des sous-emsembles (units) du processeur plus ou moins complexes comme l'ALU (Arithmetic and Logic Unit) et autres... Les détails dépendent des architectures. Celle des processeurs actuels est extrèmement complexe... et finalement, les détails nous importe peu (à moins qu'on écrive du code en assembleur, ou du code qui génère du code machine comme la partie 'back end' d'un compilateur).

Hum, je ne vois pas ce que tu appelle "mémoire programme" et "mémoire données".

Les données, si tu parle des variables ou des textes du programme, sont stockées au même endroit que le code...

Pour executer un programme, on place le prgramme et les données dans la RAM, et on indique dans le registre IP (Instruction Pointer) et IS (Instruction Segment) l'adresse et l'offset de la première instruction.

Les "données" sont sotckées dans la même mémoire, parfois avant, parfois après, parfois au milieu des insctructions, selon la façon dont on a fait le programme.

Après, il y a les différents registres qui sont utilisés pour stocker des données "temporairement" (pour réaliser un instruction, lire ou écrire sur un périphérique...

Quant à dire qu'un processeur est "assez simple", niveau logique binaire, c'est peut-être à priori simple, mais niveau electrique, electronique et physique, c'est complexe. Un Processeur normal, actuellement, contient plus d'un milliard de transistors sur une surface de quelques centimètres carrés... Gérer et mettre au points des circuits pareils, c'est pas simple

Citation : DHKold

Hum, je ne vois pas ce que tu appelle "mémoire programme" et "mémoire données".

C'est une distinction 'logique'. Même si physiquement c'est parfois la même chose[1], le comportement n'est pas le même. En cours d'exécution, il est interdit d'écrire dans la mémoire programme. D'ailleurs sur les machines munie d'une MMU (Memory Management Unit), les écritures en mémoire programmes sont interceptées brutalement (exception;, trap, message d'alerte). Ca dépend du système. Il est même possible que certaines zones de données (les chaines statiques, par exemple) soient interdites d'accès en écriture. De même tout accès en dehors de la plage autorisée (débordement de zone) est sanctionnée.

-------------------------------------
[1] Sur certaines machines très simples (8051, PIC), les zones 'programmes' et 'données' sont physiquement distinctes RAM / PROM ou Flash et on y accède pas par les mêmes instructions machine.

Citation : -ed-

En cours d'exécution, il est interdit d'écrire dans la mémoire programme.

Sur tous les procos de type x86 que j'ai pu tester, il est tout à fait possible de modifier cette "mémoire programme" en cours d'execution.

Comment les zones de la mémoire sont elles intedites d'accès? Et quel en est l'interrêt, si ce n'est rallonger le temps de traitement d'une instruction.

Mais pourquoi placer les données en PROM ou flash? C'est beaucoup plus lent d'accès, et je ne vois pas l'avantage d'une mémoire morte pour stocker des données d'un programme

Enfin, je n'ai travaillé que sur des x86

Sinon, j'ai une question. Ces deux mémoires se situe où (niveau métariel)?

Citation : DHKold

Citation : -ed-

En cours d'exécution, il est interdit d'écrire dans la mémoire programme.

Sur tous les procos de type x86 que j'ai pu tester, il est tout à fait possible de modifier cette "mémoire programme" en cours d'execution.

C'est techniquement possible pendant le chargement du programme, évidemment, mais pendant l'exécution, la zone 'programme' est vérrouillée par la MMU, du moins par les systèmes 'sérieux (Unixoïdes, MaOS, Windows NT/XP). Je ne parle pas de systèmes jouets comme DOS/Windows3.x/9.x.

Citation : DHKold

Comment les zones de la mémoire sont elles intedites d'accès?

Par re-programmation de la MMU. C'est le loader qui fait ça.

Citation : DHKold

Et quel en est l'interrêt, si ce n'est rallonger le temps de traitement d'une instruction.

Protection du code, des zones de données non modifiables... La MMU est un processus matériel autonome donc parallelle...

Citation : DHKold

Mais pourquoi placer les données en PROM ou flash?

D'abord, je parlais du code. Pour ce qui est des données, ça peut être des invariants. Enfin si on a une flash, il peut être intéressant de stocker des données permanentes (mais modifiables) dedans, donc de pouvoir les relire (au moins une fois au début du programme et après chaque modif).

Citation : DHKold

C'est beaucoup plus lent d'accès, et je ne vois pas l'avantage d'une mémoire morte pour stocker des données d'un programme

Enfin, je n'ai travaillé que sur des x86

Oui, en embarqué, on voit de drôles de choses...

Citation : DHKold

Sinon, j'ai une question. Ces deux mémoires se situe où (niveau métariel)?

Comme je me tue à l'expliquer, sur un x86, c'est la RAM (D-RAM). La différence se fait par la configuration de la MMU.

Citation : -ed-

C'est techniquement possible pendant le chargement du programme, évidemment, mais pendant l'exécution, la zone 'programme' est vérrouillée par la MMU, du moins par les systèmes 'sérieux (Unixoïdes, MaOS, Windows NT/XP). Je ne parle pas de systèmes jouets comme DOS/Windows3.x/9.x.

Ah bah là je suis d'accords, mais ce n'est plus au niveau du matériel que c'est gérer alors En fait je voulais dire que, lorsque je programme en assmebleur indépendament d'un système, et hors mode protégé, je peux fairfe ce que je veux de la mémoire dans la limite d'adressage

Citation : -ed-

D'abord, je parlais du code. Pour ce qui est des données, ça peut être des invariants. Enfin si on a une flash, il peut être intéressant de stocker des données permanentes (mais modifiables) dedans, donc de pouvoir les relire (au moins une fois au début du programme et après chaque modif).

OK, je voyais pas ca comme ca Disons que je parlais essentiellement PC, ou le disque dur joue déjà le rôle de "mémoire" pour les données à long terme

Citation : -ed-

Comme je me tue à l'expliquer, sur un x86, c'est la RAM (D-RAM). La différence se fait par la configuration de la MMU.

J'en reviens donc à ce que je dis moi aussi depuis le début, techniquement, il n'y a pas de spération Enfin, on a peut-être pas le même idée des "données" Pour moi, un texte de label, un message à afficher à l'écran, le nombre PI, dans un programme, c'est des données, et je peux t'assurer que physiquement, dans windows, elles sont exactement au même endroit que le code du programme en question dans la RAM



si je prends ce code par exemple, les deux variables que je définis sont placées en mémoire juste au début du programme. J'aurrais pu les placer après ou même au milieu

Citation : DHKold

J'en reviens donc à ce que je dis moi aussi depuis le début, techniquement, il n'y a pas de spération Enfin, on a peut-être pas le même idée des "données" Pour moi, un texte de label, un message à afficher à l'écran, le nombre PI, dans un programme, c'est des données, et je peux t'assurer que physiquement, dans windows, elles sont exactement au même endroit que le code du programme en question dans la RAM

Si on parle de PC/X86, on est d'accord, tout est physiquement dans la RAM. Mais cette RAM peut être gérée par MMU (mode protégé), et dans ce cas, on ne fait pas ce qu'on veut. Heureusement. D'ailleurs, les adresses mémoire deviennent 'virtuelles' et n'ont rien à voir avec les adresses physiques du mode réel.

Citation : DHKold

si je prends ce code par exemple, les deux variables que je définis sont placées en mémoire juste au début du programme. J'aurrais pu les placer après ou même au milieu

Ton code c'est du x86 mode réel. Ok, on est revenu aux temps anciens du mode réel, et on fait ce qu'on veut...

Moi, je te parle de ce qui se passe dans les machines actuelles PC+GNU/Linux, PC+Win XP, ou ce avec quoi je travaille actuellement : Embedded Linux sur PowerPC (carte éléctronique telecom).

Ouah, que de précisions, j'avoue que tout ça me dépasse mais merci en tout cas pour ces précisions

Vive les malades