Discussion :

[Paddington]

Bonjour,



Cela te sera très bénéfique, puisque c'est probablement le langage qui se rapproche le plus du fonctionnement réel du micro-processeur après l'assembleur lui-même. Cela reste deux langages très différents, cependant.



Ce n'est pas bien grave. La plupart des systèmes d'exploitation sont faits pour être utilisés depuis le C ou des langages de plus haut niveau. Il y aura bien un peu de programmation système à faire aujourd'hui pour pouvoir faire fonctionner ton programme dans l'environnement dans lequel tu travailles, à moins d'écrire des logiciels bootables (et de les utiliser dans une VM pour éviter de redémarrer à chaque fois).



Pas tout-à-fait. À ce stade, en fait, elle est déjà en binaire. L'hexadécimal n'est qu'une façon commode et humainement lisible de représenter les nombres, et spécialement les nombres en binaire puisqu'un chiffre hexadécimal correspond exactement à quatre chiffres binaires. Il est donc très facile de convertir l'un vers l'autre, sans avoir à faire un calcul pour effectuer la conversion.



Pour la même raison qu'il y a des Airbus et des Boeing sur le marché des avions de ligne. Même s'ils fonctionnent tous suivant le même principe, chaque assembleur va être propre à un fabricant ainsi qu'à la famille de puces que celui-ci a conçu.

Par contre : il arrive fréquemment que différents fabricants se mettent à produire leur propre version d'un même modèle de circuit, comme le 80x86 produit initialement par Intel. Ainsi, un x86 de chez AMD aura le même jeu d'instruction qu'un x86 authentique de chez Intel, puisque c'est l'idée.

C'est d'ailleurs ce qui s'est passé avec les ordinateurs à partir de 1990 et c'est d'ailleurs très regrettable. Dans les années 1980, les ordinateurs personnels étaient des huit bits. Même s'ils fonctionnaient tous suivant les mêmes grandes lignes générales, chaque fabricant proposait une gamme composée de 5 à 10 modèles de machines uniquement et chaque gamme correspondait à une famille d'ordinateurs propre, conçus depuis zéro et incompatibles (car différents) des gammes des autres fabricants. C'est ce qui se fait d'ailleurs toujours dans l'automobile, par exemple : toutes les voitures sont conçues globalement de la même façon mais indépendamment les unes des autres, et tu ne monteras pas une pièce de Volkswagen sur une Renault, sauf pour certaines parties standardisées par l'industrie, voire même définies par décret.

Ainsi, les Oric, Thomson, Amstrad CPC, Commodore (C64 et 128), etc. pour les 8 bits puis les vénérables Atari ST, et Amiga (de Commodore également) pour les 16 bits étaient tous des ordinateurs issus d'une conception propre et dotés d'une communautés d'utilisateurs bien à eux.

À partir de 1990, c'est l'IBM PC qui a supplanté tout le reste sur le marché, alors que le modèle original était cher, assez mal conçu et plus tourné vers le milieu professionnel que vers le grand public. Si bien qu'aujourd'hui, hormis Apple, les ordinateurs de différentes marques que tu peux acheter dans le commerce sont en fait tous des déclinaisons de l'IBM PC original (avec lequel ils n'ont pourtant plus grand chose en commun après 35 ans d'existence). À*tel point que les gens pensent aujourd'hui que « PC » (Personal Computer) est un terme générique pour désigner un ordinateur personnel alors qu'il s'agit au contraire d'une marque déposée.



Le nombre des instructions et leurs performances sont directement liées au micro-processeur que tu utilises. En fait, l'assembleur EST le langage de ton micro-processeur. Ce n'est pas censé être un langage interprété abstrait comme pourraient l'être le Python, le bytecode du Java ou certains langages de scripts, et qui serait ensuite reconnus ou non par différentes puces, même si on y tend un peu ces derniers temps.



Non, car c'est précisément pour cette raison que le langage C a été développé, et c'est aussi pour cela qu'il est resté populaire aussi longtemps.



La syntaxe Intel vs AMD, je n'en ai jamais entendu parler. En revanche, il y a la syntaxe Intel vs. la syntaxe AT&T. « AT&T » est la compagnie de téléphone qui possédait la Bell company et par conséquent les Bell Labs, d'où sont issus rien de moins que le transistor, UNIX et le langage C. Par conséquent, les assembleurs et compilateurs C proposés sous UNIX essaient de suivre un modèle prédéfini et assez illisible pour désigner de manière plus ou moins universelle les registres du processeur, les instructions et les différents modes d'adressage. C'est assez rébarbatif, surtout comparé à la présentation épurée qui a été choisie en parallèle par Intel et à peu près tous les fabricants de puce. Le côté historique s'opposant à l'état de l'art dans le reste de l'informatique, et comme les deux sont très répandus, beaucoup de compilateurs sont aujourd'hui capables de reconnaître les deux syntaxes, sur demande.



C'est une confusion de langage : « assembleur » désigne à la fois le type de langage lui-même et le compilateur qui va te permettre de produire du langage machine à partir de ce que tu as écrit.

Il y en a eu plusieurs, de tous temps et sur toutes les plateformes. Cependant, sur PC en particulier, MASM, pour Microsoft Assembler, a eu un grand succès dans les années 1990, puis a été presque écrasé par TASM, Turbo Assembler de Borland, qui reprenait le même modèle, en apportant beaucoup d'améliorations. Par la suite, les autres logiciels, même libres, ont choisi de se nommer plus ou moins de la même façon même si ça n'a jamais été une obligation. Les plus célèbres aujourd'hui sont NASM (Netwide Assembler) et FASM (Flat Assembler)



À ton service.

Bonjour ! Merci beaucoup pour ta réponse qui m'a aidé a un peu mieux comprendre même si il reste encore pour moi quelques questions et zones d'ombre .

Tout d'abord tu me dis que l'assembleur est le langage le plus proche du langage machine avec le C mais qu'ils sont néanmoins très différents l'un de l'autres , au final ne puis-je pas finir perdu dans toute la complexité que cela implique , le C n'est pas très compliqué du moins de ce que j'en ai vu , mais qu'en est il pour l'assembleur fais-je avoir a faire avec une foule de centaines de petits détails qui me compliqueront bien plus la vie que le C ?

Je projette aussi de faire à l'avenir ( j'ai encore le temps de voir venir mais ça ne peut pas faire de mal de s'informer sur ce qu'on veut apprendre ) de faire de la robotique , je ne sais pas si tu as déjà entendu parlé du robot nao , l'objectif pour moi serait de concevoir ce genre de robot , j'imagine que la performance étant cruciale et la place pour intégrer des puces et ce genre de chose réduite il faut un code extrêmement optimisé et rapide , c'est pourquoi j'aimerai apprendre l'assembleur en plus d'en savoir un peu plus sur le fonctionnement de la machine .

Tu me dis aussi que l'on peut convertir l'hexadécimal en binaire et inversement sans faire de calcul , même si 4 chiffres hexadécimaux correspondent à 16 chiffres binaires , on doit bien passer par du calcul pour convertir l'un en l'autre non ?

D'autre part si IBM s'est imposé à tel point que tous les ordinateurs vendus en magasin dérivent de modèles IBM que veux tu dire par la , en quoi s'inspirent ils d'IBM ? Quels composants sont semblables à ceux d'IBM ?

Ensuite , tu me dis : "Ce n'est pas censé être un langage interprété abstrait comme pourraient l'être le Python, le bytecode du Java ou certains langages de scripts, et qui serait ensuite reconnus ou non par différentes puces, même si on y tend un peu ces derniers temps "
Mais Java ou Python ne sont pas reconnus par des puces intégrés à l'ordinateur non ? Ils sont juste traduits pendant l'exécution du programme en bytecode qui lui même est transcrit en langage machine qui lui même est exécuté par le processeur ? D'autre part l'assembleur tendrait à être interprété par une puce ? Comment ça ? C'est seulement le processeur qui peut s'en charger non ? :/


Pour ce qui est des syntaxes INTEL et AT&T , je n'ai pas bien compris t'as réponses , pourquoi la syntaxe de l'assembleur est elle différente sous Linux ? L'assembleur ne dépend que du processeur non ? Les processeurs sont ils capables de comprendre les deux syntaxes ?

Pour ce qui est du programme assembleur , quel sont les différences des assembleurs ? Mis à part les langages d'assemblages qu'ils sont capables de traduire ? Pourquoi en préfère on certains à d'autres ?

Merci encore beaucoup pour ta réponse qui ma beaucoup aidée !

[Obsidian]

Tout d'abord tu me dis que l'assembleur est le langage le plus proche du langage machine avec le C mais qu'ils sont néanmoins très différents l'un de l'autres , au final ne puis-je pas finir perdu dans toute la complexité que cela implique , le C n'est pas très compliqué du moins de ce que j'en ai vu , mais qu'en est il pour l'assembleur fais-je avoir a faire avec une foule de centaines de petits détails qui me compliqueront bien plus la vie que le C ?

Oui et non : l'assembleur utilise par nature un jeu d'instruction fixe et très réduit par rapport aux grandes API des langages plus évolués. En ce sens, il est aisé de se concentrer dessus et donc de se perfectionner avec. En plus, ça te permettra de mettre en œuvre certaines techniques de programmation que tu n'auras probablement jamais l'occasion d'utiliser ailleurs.

Par contre, quand ton projet va commencer à gagner en ampleur, et surtout à interférer avec un environnement qui lui utilise une ABI adaptée à d'autres langages, alors tu vas passer ton temps à mettre en forme les appels et à décortiquer le résultat. Tu pourras t'en sortir plus facilement avec des macros mais si ton projet doit se résumer au final à une immense liste de INVOKE, ça ne vaudra vraiment plus la peine.

Je projette aussi de faire à l'avenir ( j'ai encore le temps de voir venir mais ça ne peut pas faire de mal de s'informer sur ce qu'on veut apprendre ) de faire de la robotique , je ne sais pas si tu as déjà entendu parlé du robot nao , l'objectif pour moi serait de concevoir ce genre de robot , j'imagine que la performance étant cruciale et la place pour intégrer des puces et ce genre de chose réduite il faut un code extrêmement optimisé et rapide , c'est pourquoi j'aimerai apprendre l'assembleur en plus d'en savoir un peu plus sur le fonctionnement de la machine .

L'assembleur est effectivement le meilleur moyen d'avoir une vision claire de ce qui se passe au final, quand il faut effectuer le travail. Je t'incite fortement à aller survoler le fonctionnement des différents micro-contrôleurs du marché, qui ressemblent beaucoup en pratique à ce qu'étaient les microprocesseurs 8 bits de l'époque, mais dans lesquels tu découvriras des modèles que tu rencontreras rarement sur des ordinateurs personnels. Les PIC12Cxxx, par exemple, utilisaient des mots de 12 bits pour représenter leurs codes-opérations.

Par contre, à ce que j'ai pu en voir, NAO en particulier fonctionne sous Linux : c'est en fait une sorte de mini-PC embarqué sur laquelle on installe un système d'exploitation quasiment entier que l'on peut ensuite programmer à loisir. Presque tout l'embarqué fonctionne comme cela aujourd'hui.

Tu me dis aussi que l'on peut convertir l'hexadécimal en binaire et inversement sans faire de calcul , même si 4 chiffres hexadécimaux correspondent à 16 chiffres binaires , on doit bien passer par du calcul pour convertir l'un en l'autre non ?

Oui mais tu peux faire ces calculs de tête puisqu'il n'y a que seize combinaisons possibles pour chaque chiffre hexadécimal, et comme tu sais que le poids des bits vaut respectivement 8, 4, 2 et 1 du plus fort au plus faible, il n'est pas difficile de retrouver la combinaison adéquate.

Si tu as déjà l'habitude d'utiliser « chmod » sur un système UNIX et que tu utilises directement les codes comme « 700 », « 744 » ou « 777 » pour régler tes droits, alors tu fais déjà le même exercice avec de l'octal plutôt que de l'hexadécimal.

D'autre part si IBM s'est imposé à tel point que tous les ordinateurs vendus en magasin dérivent de modèles IBM que veux tu dire par la , en quoi s'inspirent ils d'IBM ? Quels composants sont semblables à ceux d'IBM ?

Je veux dire que ce sont tous des « PC », ce qui signifie « Personal Computer », ce qui n'a jamais été un nom commun, mais qui était au contraire une marque déposée d'un modèle bien précis d'ordinateur produit par une compagnie bien précise elle-aussi.

Depuis les années 1980, les fabricants de PC produisirent des ordinateurs dits « compatibles PC », qu'on appelait aussi « compatibles IBM ». Donc officiellement, c'était des ordinateurs complètement indépendants mais logiciellement compatibles avec ce qui tournait sur « l'IBM PC ». En pratique, c'était des clones de la machine initiale, obtenus par reverse engineering et donc plus ou moins fidèles au modèle original. IBM a laissé faire, volontairement à ce que je sais. Le comble, c'est qu'aujourd'hui, IBM ne produit plus de PC du tout, et a cédé ses dernières lignes consacrées la chose.

C'est un peu comme si aujourd'hui, 99 % des fabricants d'automobiles étaient des petites structures et qu'elles se mettaient toutes à copier la Golf de VW en particulier. En 20 ans, tous les autres constructeurs auraient disparu et côté modèle, il serait difficile d'expliquer pourquoi une automobile n'est pas forcément une Golf, et que les autres automobiles se valaient mais sans être « compatibles » entre elles. Il serait encore plus difficile d'expliquer en quoi cette diversité était vertueuse en dépit des problèmes d'harmonisation de la production que cela pouvait poser aux équipementiers. C'est très caricatural, mais il est de fait que c'est ce qui s'est passé dans l'informatique grand public.

Ensuite , tu me dis : "Ce n'est pas censé être un langage interprété abstrait comme pourraient l'être le Python, le bytecode du Java ou certains langages de scripts, et qui serait ensuite reconnus ou non par différentes puces, même si on y tend un peu ces derniers temps " Mais Java ou Python ne sont pas reconnus par des puces intégrés à l'ordinateur non ? Ils sont juste traduits pendant l'exécution du programme en bytecode qui lui même est transcrit en langage machine qui lui même est exécuté par le processeur ?

En principe oui, mais certaines puces pouvant reconnaître directement le bytecode ont été produites, au moins pendant un temps. Après, il est difficile de dire si elles avaient été conçues directement comme ça ou s'il s'agissait en fait d'un micro-contrôleur traditionnel embarquant une JVM logicielle.

Pour ce qui est des syntaxes INTEL et AT&T , je n'ai pas bien compris t'as réponses , pourquoi la syntaxe de l'assembleur est elle différente sous Linux ? L'assembleur ne dépend que du processeur non ? Les processeurs sont ils capables de comprendre les deux syntaxes ?

Les microprocesseurs ne comprennent que le langage machine. L'assembleur va représenter ces codes-opérations par des mnémoniques humainement lisibles. Ce sont eux qui sont mis en forme selon une syntaxe bien définie également pour que les compilateurs puissent les reconnaître et faire leur travail.

Pour ce qui est du programme assembleur , quel sont les différences des assembleurs ? Mis à part les langages d'assemblages qu'ils sont capables de traduire ? Pourquoi en préfère on certains à d'autres ? Merci encore beaucoup pour ta réponse qui ma beaucoup aidée !

Ça c'est essentiellement une question de goût de la part du programmeur. On peut dire toutefois que les produits sortis après les premiers et devenus plus populaires le sont généralement devenus parce qu'ils corrigeaient des bugs, introduisaient quelques fonctionnalités supplémentaires (prise en charge de macros plus sophistiquées) et s'adaptaient à l'évolution des machines : par exemple, TASM a été très utilisé sous DOS parce que c'était un bon produit mais également parce qu'il était beaucoup facile de programmer en assembleur sous DOS. Il était donc très adapté au 16 bits, il a été décliné en 32 bits mais, à ma connaissance, jamais en 64.

Aujourd'hui, les plate-formes sur lesquelles ces produits sont disponibles vont avoir beaucoup d'importance (NASM fonctionne très bien sous Linux, par exemple), ainsi que les licences qui sont associées : le fait d'être un logiciel libre et au code source ouvert lui permet d'être distribué très largement

[chrtophe]

Tout d'abord tu me dis que l'assembleur est le langage le plus proche du langage machine avec le C mais qu'ils sont néanmoins très différents l'un de l'autres , au final ne puis-je pas finir perdu dans toute la complexité que cela implique , le C n'est pas très compliqué du moins de ce que j'en ai vu , mais qu'en est il pour l'assembleur fais-je avoir a faire avec une foule de centaines de petits détails qui me compliqueront bien plus la vie que le C ?

Exemple d'affectation de variable en C :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int entier;
entier=5;

en assembleur x86 (chargement dans le registre 32 bits EAX, car en assembbleur on passe par des registres, ce que tu verras dans tes premiers cours):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov 5,eax

en assembleur 68000 dans le registre d0 (ancien CPU présent dans les Atari ST, les Amigas, les vieux Macintosh, les anciennes imprimantes tels que les laserjets anciennes générations) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
move.w d0,5

On voit tout de suite que c'est plus lisible en C et qu'en changeant de CPU, la syntaxe change et qu'il te faut t'adapter. Et là j'ai pris que deux CPUs. Tu remarquera aussi qu'avec l’exemple x86 on place d'abord la destination puis la source.

Compliquons un peu :

Si je prends la syntaxe Intel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov 5,eax

Si je prends la syntaxe AT&T :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
 movl $0x5, %eax

Et là je ne parle même pas d'afficher un message à l'écran.

D'autre part si IBM s'est imposé à tel point que tous les ordinateurs vendus en magasin dérivent de modèles IBM que veux tu dire par la , en quoi s'inspirent ils d'IBM ? Quels composants sont semblables à ceux d'IBM ?

C'est IBM qui a inventé le PC. Celui-ci a été cloné et est devenu une norme.

pourquoi la syntaxe de l'assembleur est elle différente sous Linux ?

La syntae AT&T éxistait avant celle d'Intel. Les deux sont utilisables, mais par défaut, c'est la AT&T qui est utilisé avec l'assembleur fourni de base avec les Unix. NASM utilise la syntaxe Intel, mais n'est pas installé de base.

Un compilateur va traduire le code C (ou autre dans le cas d'un autre langage) en assembleur pour le CPU sur lequel il fonctionne. Puis ce code assembleur sera ensuite traduit en langage machine (suite de chiffres hexadécimaux incompréhensible pour l'être humain).

[sambia39]

Bonjour ! Merci beaucoup pour ta réponse qui m'a aidé a un peu mieux comprendre même si il reste encore pour moi quelques questions et zones d'ombre .

Tout d'abord tu me dis que l'assembleur est le langage le plus proche du langage machine avec le C mais qu'ils sont néanmoins très différents l'un de l'autres , au final ne puis-je pas finir perdu dans toute la complexité que cela implique , le C n'est pas très compliqué du moins de ce que j'en ai vu , mais qu'en est il pour l'assembleur fais-je avoir a faire avec une foule de centaines de petits détails qui me compliqueront bien plus la vie que le C ?

Le langages C et le langage assembleur sont dit proches de la machine ou encore dite langage de programmation bas niveaux pour des raisons qui leur sont bien propres. L'assembleur en premier est le langage qui est bien plus proche de la machine que le langage C car, il s'adresse directement à la machine en clair, directement au processeur mais aussi difficile pour certaines raisons exemple: il n'est pas évident de ce souvenir et de savoir de façon complète ou générale à quoi cert ses nombreuses instructions de plus quand vous programmez en assembleur vous devez connaitre l'architecture cible pour que l'application fonctionne dessus et il faut également aimer un temps de développement long (crée un programme totalement en assembleur demande du temps).
Le langage C quant à lui est également dit bas niveaux d'une part parce qu'il apporte une couche supplémentaire ( c'est-à-dire, qu'il fournit et effectue des opérations qui sont très proches de ceux du langage machine), mais aussi parce qu'elle fournit également des fonctions qui permettent d'avoir un accès aux fonctions internes de l'ordinateur comme par exemple: la manipulation mémoire ou la gestion de celle-ci. Elle possède également un avantage par rapport à l'assembleur car il est portable c'est-à-dire, qu'il faut juste recompiler voir compiler le code source écrit pour qu'il soit fonctionnel sur un ordinateur en respectant le standard de probabilité des programmes écrits en langage C (référence à ANSI C).

Le plus compliquer des deux est l'assembleur de mon point de vue car, le langage lui-même dépendant de l'architecture cible mais aussi du système; on ne programme pas en assembleur GNU/Linux exactement comme sous Windows et on ne effectue pas les mêmes appels système Windows comme sous GNU/Linux tout simplement parce que ce sont deux systèmes profondément différents et qui embarquent des API qui leur sont propres.
En assembleur "oui" il faut faire attention au détaille et justement ces différent détaille qui implique la de connaitre le processeur ou le microprocesseur cible.
Pour éviter de tout faire en langage assembleur, vous avez également la possibilité de l'écrire directement dans du langage C, C++, pascale etc. pour plus de souplesse exemple avec le code source ci-dessous à titre d'exemple non tester.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
/*	
	Exemple de programme qui inclut
	ou embarque le langage assembleur 
	dans du langage C ce code est 
	a compiler sous du visual c++
*/
 
#include <stdio.h>
#include <stdlib.h>
 
/*
	Fonction qui ajoute 250 
	a chaque nombre	
*/
int f_AddMax( int var ){
	_asm{
		mov eax, var		; Met var dans eax
		add eax, 250		; ajoute 250 a eax
		return x			; retourne le résulat
	}
}
 
/*	
	Programme principale
*/
int main( void ){
 
	int x = 10;
	x = f_AddMax( x );
	fprintf( stdout, "%d\n", x );
 
	return EXIT_SUCCESS;
}

Je projette aussi de faire à l'avenir ( j'ai encore le temps de voir venir mais ça ne peut pas faire de mal de s'informer sur ce qu'on veut apprendre ) de faire de la robotique , je ne sais pas si tu as déjà entendu parlé du robot nao , l'objectif pour moi serait de concevoir ce genre de robot , j'imagine que la performance étant cruciale et la place pour intégrer des puces et ce genre de chose réduite il faut un code extrêmement optimisé et rapide , c'est pourquoi j'aimerai apprendre l'assembleur en plus d'en savoir un peu plus sur le fonctionnement de la machine .

Personnellement, je t'encourage pour tes ambitions futures. Et la robotique est un domaine fascinant.
Cependant, les performances sont cruciales selon les objectifs que l'on vise ou que l'on veux atteindre et ils sont là pour évaluer et permettre de faire un choix en comparaison les résultats obtenue après un teste de performances et les résultats théoriques (mathématique) obtenus grâce à la résultante de l’évaluation par complexité. Et cela s'applique exemple au algorithme , au système informatique lui même exemple faire des teste de performance sur un système informatique en simulant la plus haute l'activité attendue ou pas afin de savoir comment le système réagi ou agis (teste de stress) si c'est ce que vous entendez par performance.
Pour ce qui est la place ou autres objets réduits, ce n'est pas une question de performance mais de miniaturisation le domaine de la nanotechnologie que je connais peu de choses.
Et pour la rapidité du code, elle dépend fortement de l'algorithme exemple: si vous écrivez votre algorithme d'une façon médiocre et l'implémenter en langage C il ne sera pas plus rapide qu'un algorithme ayant le même objectif que le vôtre implémenté dans le même langage au dans un autre langage de programmation.

Ensuite , tu me dis : "Ce n'est pas censé être un langage interprété abstrait comme pourraient l'être le Python, le bytecode du Java ou certains langages de scripts, et qui serait ensuite reconnus ou non par différentes puces, même si on y tend un peu ces derniers temps "
Mais Java ou Python ne sont pas reconnus par des puces intégrés à l'ordinateur non ? Ils sont juste traduits pendant l'exécution du programme en bytecode qui lui même est transcrit en langage machine qui lui même est exécuté par le processeur ? D'autre part l'assembleur tendrait à être interprété par une puce ? Comment ça ? C'est seulement le processeur qui peut s'en charger non ? :/.

En plus de ce qui a été dit a ce sujet, il faut savoir ce que c'est un langage compilé et interprété et leur différence.
pour faire simple, programme compiler est fait une fois pour toute pour la machine le système cible windows ou linux et pour une autre cible le même code source doit être recompilé. Un programme interpréter quand a lui est t'un programme qui dépend d'un interpréteur qui traduit le code à la volée le code c'est-à-dire, traduire au fur et à mesure le code source en code machine. Donc (admettant) si un micro-processeur embarque un interpréteur java comme ce qui a été dit votre code fonctionneras.

à bientôt

[Kannagi]

en assembleur 68000 dans le registre d0 (ancien CPU présent dans les Atari ST, les Amigas, les vieux Macintosh, les anciennes imprimantes tels que les laser-jets anciennes générations) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

move.w d0,5

Cela doit faire longtemps que tu n'as pas fait du 68000 , ce que tu as écris signifie que le contenu du registre d0 va dans l'adresse mémoire 5.

Parce que chez moi pour mettre la valeur 5 sur le registre d0 je l'écris comme cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

move.w #5,d0

Voila je chipote un peu dessus ^^'

[sambia39]

Exemple d'affectation de variable en C :

en assembleur x86 (chargement dans le registre 32 bits EAX, car en assembbleur on passe par des registres, ce que tu verras dans tes premiers cours):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mov 5,eax

Peut-être que je me trompe mais ce n'est pas plutôt le contraire 5 dans EAX et non EAX dans 5 ?

Code ASM :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
section	.text
	global _start
_start: 
 
	mov 5, eax ; error: invalid combination of opcode and operands 
	mov eax, 5 ; Compile ok
section	.data

à bientôt

[chrtophe]

Cela doit faire longtemps que tu n'as pas fait du 68000

Oui tu as raison; d'ailleurs il n'existe plus le 68000.

Voila je chipote un peu dessus

Peut-être, car selon l'assembleur, ça peut peut-être passer... (pour le #, pas pour l'inversion)

Peut-être que je me trompe mais ce n'est pas plutôt le contraire 5 dans EAX et non EAX dans 5 ?

tu as aussi raison, En fait, j'ai inversé les deux ( à la Intel )

car, Paddington, on ne fait quasiment plus d'assembleur pour autre chose que l'utilisation de micro-controleurs. Et encore, on utilise maintenant aussi le C avec par exemple uClibc (les utilisateurs de micro-controleurs pourront te donner plus de détails).

Les compilateurs actuels sont capables de générer du code machine aussi voire plus efficace que toi en assembleur. Mais il y a des cas ou il reste nécessaire (exemple accès aux registres CPU pour activer la pagination si tu crée un OS).

Pour conclure l'assembleur, c'est du très bas niveau, le C permet de faire du bas niveau mais aussi du plus haut niveau pour un usage simple comme l'appel à printf. Les langages interprétés tels que PHP, ou PYTHON sont de plus haut niveau et on été probablement écris en C.