Bonjour,

je voudrais savoir si il existe sur ce site ou sur un autre site, un cour pour apprendre a programmer
en "Binaire" (le langage machine)???

Si ce cour existe je vous remercie d'avance de m'indique son lien...


Merci pour vos réponses!!!

Ce tutoriel n'existe pas.

Et je parie qu'il n'existera jamais.

Déjà, il faut savoir qu'a chaque marque de processeur différent correspond un langage binaire différent. Rien que ca, ca risque de calmer pas mal.

Et puis sache qu'il existe un langage nommé assembleur qui fait exactement la même chose que le langage binaire, mais qui est beaucoup plus facile à utiliser. Il se peut qu'un tutoriel assembleur sorte un jour sur le site du zéro, mais ce n'est pas pour tout de suite : il y en a deux en projet, et ca semble avancer lentement.

Citation : mewtow

mais qui est beaucoup plus facile à utiliser.

Oui enfin bon ... En tout cas, l'intérêt d'apprendre l'assembleur est très limité et, sauf dans des cas très spécifiques (dans les systèmes embarqués notamment), l'assembleur te servira très peu car c'est trop dépendant de l'architecture de ton processeur et on l'utilise surtout pour optimiser (quand c'est réellement utile) du code C. Mais dans le monde du travail par exemple, que tu marques que tu sais faire un programme en assembleur n'a aucun intérêt.

Après, la difficulté avec ce langage n'est pas vraiment dans les notions (c'est du par coeur en général) mais dans la conception d'un programme car tu es très limité dans les instructions et il te faudra réfléchir (souvent pour pas grand chose) et c'est surtout une perte de temps. Après, dans le cadre d'un apprentissage, cela permet de voir comment fonctionne un ordinateur mais en général, on passe très vite son chemin avec ce langage et, AMHA, le C est amplement suffisant pour comprendre comment fonctionne globalement un ordinateur.

Hé on parle pas assembleur hein , mais binaire
C'est différent...

Le language binaire n'existe pas, ce n'est pas un language
Quelle idée de vouloir faire un truc pareil?

> tigzy : il existe bel et bien un langage appelé le langage machine, intégralement écrit en binaire, équivalent à l'assembleur.

J'en parle dans mon tutoriel en béta-test "fonctionnement d'un ordinateur depuis zéro".

En gros, c'est un langage écrit uniquement avec des 0 et 1, dans lequel une suite de 0 ou 1 peut signifier :

• soit une instruction
• soit une adresse
• soit un nombre

Il suffit de donner des noms à chaque instruction, et utiliser les valeurs numériques des adresse/nombre pour obtenir l'assembleur.

- enfin c'est très résumé tel qu'expliqué ici.

Citation : Dinosaure

le C est amplement suffisant pour comprendre comment fonctionne globalement un ordinateur.

C'est une blague ?

OK, je veux bien accepter le fait que le C est "proche" du matériel, mais de là à dire que le C permet de savoir pas mal de ce qui se passe dans un ordinateur...C'est de la mauvaise foi. Déjà, rien que l'assembleur peut facilement être considéré comme un langage bas niveau !

En assembleur, tu apprends directement à manier la pile, faire des branchements, triturer des registres, bosser avec des adresses mémoires, manipuler des segments, et des tas d'autres choses que l'on ne voit jamais en C. Franchement le C, ca apprend pas mal les structures de contrôle, mais niveau fonctionnement d'un PC, c'est ultra-pauvre !

Citation : mewtow

En assembleur, tu apprends directement à manier la pile,

va_arg.

Citation : mewtow

faire des branchements,

if et goto.

Citation : mewtow

triturer des registres,

Là, d'accord.

Citation : mewtow

bosser avec des adresses mémoires,

C'est quoi un pointeur ?

Citation : mewtow

manipuler des segments,

Quasi inutile.

Citation

En assembleur, tu apprends directement à manier la pile, faire des branchements, triturer des registres, bosser avec des adresses mémoires, manipuler des segments, et des tas d'autres choses que l'on ne voit jamais en C. Franchement le C, ca apprend pas mal les structures de contrôle, mais niveau fonctionnement d'un PC, c'est ultra-pauvre !

Déjà, le langage C est considérer comme bas niveau bien que les programmes en C sont non-réversibles (mais ça on s'en fout). De plus, la définition que tu nous donnes d'un langage bas niveau (pour l'assembleur) correspond aussi avec le C comme le montre 1337833K. Et je termine aussi par dire qu'il est souvent contre-productif de faire un programme en assembleur car, aujourd'hui, les compilateurs permettent d'optimiser le programme compilé de manière à ce qu'il soit plus performant qu'un programmeur ne pourrait le faire. L'assembleur s'utilise seulement dans des cas où on ne peut pas faire autrement (notamment quant on est limiter niveau matériel ou quant on a besoin des spécificités d'une architecture) mais après, ce n'est pas parce que vous programmer en assembleur que votre programme sera plus rapide.

Citation : 1337833K

va_arg.

Et il y a aussi un truc qui permet d'allouer directement des variables sur la pile. Faut que je m'en rappelle trop tard...

Citation : 1337833K

if et goto.

If n'est pas un branchement, mais d'accord pour goto, break, et continue. Sans compter surement d'autres, un peu cachés (pointeurs sur fonctions ?).

Citation : 1337833K

C'est quoi un pointeur ?

Effectivement.

Ces corrections sont bienvenues. Vaut mieux pas trop laisser mes conneries sans correction.

> dinosaure, je répondais à ca :

Citation : dinosaure

le C est amplement suffisant pour comprendre comment fonctionne globalement un ordinateur.

Pour moi, c'est juste faux. Il y a pas mal de concepts de l'architectures d'un ordinateur qui sont directement manipulables en ASM qui sautent en C : registres, instructions machines... Une partie de la complexité de l'architecture d'un PC est quand même camouflée par le langage.

Je n'ai jamais abordé le fait de programmer en C ou ASM. Même si tes remarques sont justes (difficile de le nier), j'ai juste réagit sur ta phrase. Sur l'utilité pédagogique de ces langage, pas de leur utilité dans le développement.

Et non, le C n'est pas toujours considéré comme un langage bas niveau. Mon avis sur al question est écrit juste là (c'est moi l'auteur de cette page) : lien wiki.

En tout cas, dans mes études d'électronique, qui me destinent à coder dans l'embarqué (avec de la chance), on considérait le C comme de haut niveau. Bien sur, un informaticien généraliste ne sera pas habitué à un langage aussi proche du matos, et considérera le C comme de haut niveau. Question de "mode" ou de "mentalité".

Citation

tigzy : il existe bel et bien un langage appelé le langage machine, intégralement écrit en binaire, équivalent à l'assembleur.

Oui, mais ce n'est pas un langage de programmation

Citation : tigzy

Citation

tigzy : il existe bel et bien un langage appelé le langage machine, intégralement écrit en binaire, équivalent à l'assembleur.

Oui, mais ce n'est pas un langage de programmation

Bien sur que si, on peut parfaitement programmer avec. Exactement comme en assembleur. A vrai dire, c'est exactement comme l'assembleur.

Et il ne faut pas confondre le binaire (la base 2), et le langage binaire, qui permet d'écrire des programmes en langage machine (souvent, par abus de langage, on confond langage machine et binaire).

Enfin en théorie, car en pratique, faut vraiment être en état de masochisme avancé pour oser faire ca.

Le langage binaire, et le binaire, pour moi c'est identique.
Le langage binaire, c'est uniquement une interprétation du binaire en instructions ASM.

Citation : tigzy

Le language binaire, et le binaire, pour moi c'est identique.
Le language binaire, c'est uniquement une interprétation du binaire en instructions ASM.

Non. Le binaire est un système numérique de base 2.
Le langage binaire est un langage que peut interpréter une machine sans autre traitement.
L'ASM est une notation plus facile à lire.

Citation : 1337833K

Citation : mewtow

triturer des registres,

Là, d'accord.

read/write.
Très utiles pour les modules.

Citation

Le binaire est un système numérique de base 2.
Le langage binaire est un langage que peut interpréter une machine sans autre traitement.

Sauf que visuellement parlant, c'est identique.
C'est comme faire le distinguo entre l'alphabet et une langue, l'organisation de lettre forment des mots interprétable dans une certaine langue.

Simple apparte,
if est un branchement conditionnel, dans l'architecture MIPS ca correspondrait a un branch on... (equal, not equal, greater than zero, etc.)

Le terme "langage binaire" (et pas "language", non mais...) ne veut pas dire grand chose. Un langage est défini par sa grammaire plutôt que la façon dont ses phrases sont stockées. Écrire en UTF8 dans un éditeur de texte, dessiner à la craie au tableau, ou écrire en alternant 0 et 1 dans un fichier binaire, ça reste le même langage. Si tu veux parler du langage légèrement plus primitif résultant de la compilation du code assembleur, dont les programmes sont stockés dans les exécutables, il vaut mieux parler de "langage machine".

Citation

Le terme "langage binaire" (et pas "language", non mais...)

Déformation professionnelle

Citation : bluestorm

Un langage est défini par sa grammaire plutôt que la façon dont ses phrases sont stockées.

Un langage, ce n'est pas qu'une grammaire, c'est aussi une suite de symboles sur lesquels appliquer cette grammaire. Entre une suite de bits et une suite de lettres/chiffres, il y a une différence.

Il n'est pas stupide d'appeler langage binaire et ASM par deux noms différents, et les qualifier tous les deux de langages.

Citation : Adroneus

Simple apparte,
if est un branchement conditionnel, dans l'architecture MIPS ca correspondrait a un branch on... (equal, not equal, greater than zero, etc.)

If n'est pas un branchement conditionnel, c'est :

• Une instruction de test
• suivie d'un branchement conditionnel.

On a donc deux instructions placées l'une à la suite de l'autre.

Il faut savoir que le branchement est exécute si une condition est valide. Mais il faut savoir si cette condition est valide avant de faire quoique ce soit. Et pour cela, il faut exécuter une instruction de test. Je vais me permettre de citer mon tutoriel en béta test pour clarifier la situation. Tout est éxpliqué en détail là dedans : test et branchements.

Citation

Un langage, ce n'est pas qu'une grammaire, c'est aussi une suite de symboles sur lesquels appliquer cette grammaire. Entre une suite de bits et une suite de lettres/chiffres, il y a une différence.

Il y a une différence, mais elle n'est pas importante et ne mérite pas qu'on s'y attarde. On ne dit pas qu'on utilise un langage différent quand on code un programme en UTF8 ou en ASCII, pourtant les symboles sont différents. La signification est la même et les programmes sont comparables en tout point.

Si on fait une différence entre le code assembleur et le code machine, c'est parce que les langages sont différents. Pour passer d'un code assembleur typique à un code machine, il y a une étape de compilation (disparition des noms de labels remplacés par des offsets, par exemple), puis de liage, et la génération d'un exécutable respectant le format de la plateforme (qui contient donc des entêtes supplémentaires, etc.).

Cette différence là justifie la distinction entre les langages. Pas le faire d'écrire "GOTO" ou "010110". D'ailleurs, le terme "binaire" est malvenu puisque la plupart des exécutables ont une granularité beaucoup plus forte, au niveau de l'octet en général, et sont édités/visualisés en hexadécimal.



Au sujet du branchement conditionnel, je ne vois pas l'intérêt de ta distinction. Selon toi un branchement conditionnel, c'est comme un branchement non conditionnel, sauf que l'instruction d'avant est un test. À quoi sert la distinction "conditionnel / non conditionnel" alors ? Je préfère dire, comme Adroneus, qu'un branchement conditionnel est une instruction qui effectue un branchement _si une condition est vraie_ (donc elle contient un test), plutôt que voir ça comme deux instructions (de toute façon le découpage au final dépend de beaucoup d'autres facteurs).

Par ailleurs les schémas de ton tutoriel sont aussi un peu discutables. Par exemple dans ta traduction de if..then..else tu as un branchement conditionnel pour entrer dans le then, un branchement non conditionnel pour entrer dans le else, puis un branchement à la fin de chaque bloc pour sauter à la suite du code. En pratique les compilateurs sont souvent plus directs, par exemple ils mettent le code du else directement à la suite du test, ce qui économise un branchement, et pareil en sortie (on peut coller le code du if ou de else juste avant la suite du code, pour là encore économiser un branchement).
La représentation entièrement découpée est typiquement plutôt utilisée dans d'autres étapes un peu plus haut niveau d'un compilateur, comme le RTL.


Ceci dit, je pense qu'il n'est pas forcément la peine de couper les cheveux en quatre sur ce genre de choses. Il y a un peu de flexibilité sur ces définitions, et du moment que les gens comprennent ce que tu veux dire, tu peux choisir une présentation plutôt qu'une autre. Mais je trouve que tu ne devrais pas être aussi pointilleux et catégorique quand tu t'exprimes, puisque justement il n'y a pas forcément une unique "vraie définition".

Citation : bluestorm

Au sujet du branchement conditionnel, je ne vois pas l'intérêt de ta distinction. Selon toi un branchement conditionnel, c'est comme un branchement non conditionnel, sauf que l'instruction d'avant est un test. À quoi sert la distinction "conditionnel / non conditionnel" alors ? Je préfère dire, comme Adroneus, qu'un branchement conditionnel est une instruction qui effectue un branchement _si une condition est vraie_ (donc elle contient un test), plutôt que voir ça comme deux instructions (de toute façon le découpage au final dépend de beaucoup d'autres facteurs).

Et bien essaye de mettre un branchement conditionnel sans test avant, tu aura des surprises. Ton branchement s'exécute si un bit particulier du registre d'état du processeur est placé à 1 (ou 0, c'est selon). Enlève le test qui positionne ce bit à la bonne valeur et tu aura des problèmes. Il y a bien deux instructions machines, pas une. Et appeler une expression d'un langage de haut niveau du style if...then...else ou je ne sais quoi une instruction, c'est une énorme erreur. Ce n'est pas couper les cheveux en quatre.

Citation : bluestorm

Par ailleurs les schémas de ton tutoriel sont aussi un peu discutables. Par exemple dans ta traduction de if..then..else tu as un branchement conditionnel pour entrer dans le then, un branchement non conditionnel pour entrer dans le else, puis un branchement à la fin de chaque bloc pour sauter à la suite du code. En pratique les compilateurs sont souvent plus directs, par exemple ils mettent le code du else directement à la suite du test, ce qui économise un branchement, et pareil en sortie (on peut coller le code du if ou de else juste avant la suite du code, pour là encore économiser un branchement).

Merci pour la précision. Je corrige tout de suite.

Bon pour ma défense, j'avais bien marqué que les suites d'instructions étaient faites sans optimisations. Mais ca n'en reste pas moins une "erreur".

Sinon, dans mon tutoriels, est-ce que la partie sur les if...else if... est correcte ? Je veux dire, il n'y a pas d'optimisations comme celle que tu as cité au dessus ?

Citation : mewtow

Et bien essaye de mettre un branchement conditionnel sans test avant, tu aura des surprises. Ton branchement s'exécute si un bit particulier du registre d'état du processeur est placé à 1 (ou 0, c'est selon). Enlève le test qui positionne ce bit à la bonne valeur et tu aura des problèmes. Il y a bien deux instructions machines, pas une.

C'est faux, ou plutôt ça dépend des architectures. Sur l'architecture MIPS citée par Adroneus, il y a bien des instructions machine pour des branchement conditionnels qui font aussi des tests. Par exemple beq rs, rt, label est une instruction qui effectue le branchement vers label si les valeurs des registres rs et rt sont égales. C'est bien une seule instruction, qui a un opcode, etc.

Citation

Sinon, dans mon tutoriels, est-ce que la partie sur les if...else if... est correcte ? Je veux dire, il n'y a pas d'optimisations comme celle que tu as cité au dessus ?

J'imagine qu'il y a plein d'optimisations possibles et imaginable, mais si tu commences à vouloir toutes les décrire tu ne vas pas t'en sortir. Je dois avouer que je ne suis pas tout à fait convaincu par la façon dont tu organises les choses dans ton tutoriel. Tu dis qu'il ne faut pas savoir programmer... mais en pratique tu enseignes plus ou moins la programmation assembleur, mais en même temps ce n'est pas vraiment l'assembleur (tu expliques surtout des structures plus haut niveau et leurs décompositions en instructions), et je ne vois pas trop qui va trouver ça compréhensible et intéressant à part des gens qui savent déjà programmer (ou plutôt, je pense que les gens qui trouveront intéressant et compréhensible ton tutoriel auraient sans doute eu besoin de moins d'effort pour le lire s'ils avaient appris les bases de la programmation avant).

Dans tous les cas, vu l'étendue du sujet, je pense que tu ne peux pas viser l'exactitude absolue, mais plutôt essayer une forme de vulgarisation où le but n'est pas de donner des connaissances techniques précises, mais de donner aux gens une bonne idée d'ensemble de comment ça marche pour leur permettre d'approfondir avec des sources plus spécialisées ensuite.

L'assembleur reste une expérience intéréssante. Il permet mieux comprendre comment fonctionne concrètement un ordinateur

Je viens juste de commencer a lire ton tutoriel, je ne sais pas si c'est franchement utile a preciser, ( mais je pense que oui, programmant en C, je me suis deja retrouve dans le cas de figure ou on me precisait que le byte n'etait pas egal a 8 bits ) de rappeller qu'un byte n'equivaut pas forcement a un octet : http://fr.wikipedia.org/wiki/Byte

simple petite remarque au passage

Citation : Adroneus

Je viens juste de commencer a lire ton tutoriel, je ne sais pas si c'est franchement utile a preciser, ( mais je pense que oui, programmant en C, je me suis deja retrouve dans le cas de figure ou on me precisait que le byte n'etait pas egal a 8 bits ) de rappeller qu'un byte n'equivaut pas forcement a un octet : http://fr.wikipedia.org/wiki/Byte

simple petite remarque au passage

Ah oui, ca me rappelle le codage des octets quand on utilise un bit de parité : on se retrouve avec un octet de 9 bits.

Mais décidément j'en aurais des appris trucs en une soirée xD

Merci pour toutes ces précisions.

Citation : mewtow

Ah oui, ca me rappelle le codage des octets quand on utilise un bit de parité : on se retrouve avec un octet de 9 bits.

T'as pas l'impression qu'il y a un truc pas logique dans cette phrase ?
Un octet, tu peux faire ce que tu veux avec, ça fera toujours 8 bits.

Il voulait dire byte je pense