Programmer en Assembleur pour Windows XP

Version imprimable

29/07/2010, 20h59
fgh39

Programmer en Assembleur pour Windows XP

Ayant de bonnes bases d'asm pour µ-contrôlleur Motorola 8/16 bit, je voudrais me mettre a l'asm 32/64 bit pour PC, car dans certains cas cela me semble plus pratique que le C lol!. Par exemple pour lire une valeur du port imprimante...
Je désire écrire des programmes pour Windows 2000, XP, Vista et Linux et les intégrer dans du code orienté C ou autre (GTK).
Je suis informé qu'il y a un problème d'accès aux périphériques sous Windows. Comment contourner ces problèmes ?
Aussi j'ai eu des informations sur le contrôleur d'interruption d'un PC qui ne fonctionne pas vraiment comme un µ-contrôleur.

Enfin, j'ai eu un bref aperçu de Nasm, il existe yasm, fasm et bien d'autres compilateurs. Lequel est le plus pratique et pas forcément le plus a jour ?

Je cherche un tutoriel surtout pour Windows XP en mode 32bits (flat je crois), car linux me semble plus accessible.

Merci d'avance.
29/07/2010, 21h44
Obsidian

Bonjour,

Citation:

Envoyé par fgh39

Ayant de bonnes bases d'asm pour µ-contrôlleur Motorola 8/16 bit, je voudrais me mettre a l'asm 32/64 bit pour PC, car dans certains cas cela me semble plus pratique que le C lol!. Par exemple pour lire une valeur du port imprimante...
Je désire écrire des programmes pour Windows 2000, XP, Vista et Linux et les intégrer dans du code orienté C ou autre (GTK).

Si c'est le cas, alors il faut faire de la programmation système dans le langage le plus adapté à ton système (donc C, généralement) plutôt qu'utiliser l'assembleur pour accéder directement au matériel. D'abord parce que même en assembleur, ton système ne te laissera pas le faire, ensuite parce que si tu y parviens, tu risques de mettre le tout dans un état instable et de provoquer de gros effets de bord.

L'exemple-type est la lecture du port PS/2. À l'époque du DOS, on le faisait beaucoup, surtout dans les démos, pour savoir si une touche quelconque était enfoncée, ou si c'était ESC qui l'était en particulier. Seulement, le trafic souris passait par le même port et lancer un tel programme dans un environnement graphique provoquait une désynchronisation des trames, ce qui fait que le pointeur de souris devenait fou et aller se balader et cliquer dans tous les coins.

Citation:

Je suis informé qu'il y a un problème d'accès aux périphériques sous Windows. Comment contourner ces problèmes ? Aussi j'ai eu des informations sur le contrôleur d'interruption d'un PC qui ne fonctionne pas vraiment comme un µ-contrôleur.

Il faut que tu apprennes ce qu'est le mode protégé si ce n'est pas déjà fait. Tous les systèmes modernes l'utilisent, Linux compris. Pour contourner ces problèmes, soit un écrit un pilote de périphérique ou un module noyau Linux qui tournera directement en espace privilégié, soit il faut demander au système l'autorisation expresse d'accès à certains ports à l'aide d'appels systèmes, s'ils existent (ioperm() et iopl() sous Linux, spécifiquement).

Citation:

Enfin, j'ai eu un bref aperçu de Nasm, il existe yasm, fasm et bien d'autres compilateurs. Lequel est le plus pratique et pas forcément le plus a jour ?

Moi, j'utilise nasm et il me convient bien. À ce stade, il faut les essayer toi-même et faire ton choix.
30/07/2010, 15h30
fgh39

Merci pour la réponse.
Pour la programmation en asm PC, je ne sais pas si ce serait utile (je pense que oui) qu'il faut connaitre ce qu'on appelle le mapping d'un pc (bref ce qui est inscrit dans quelque chose qui ressemble a une norme) ==> Là ou sont les adresse des ports (graphique, PCI, usb, rs232, //, hdd, timer, horloge temps réel, mémoire systèmes et son contrôleur, etc ...
J'avais lu sur une doc que c'est en haut de l'espace adressable par le cpu central.
Ensuite les niveaux de droits allant du SU aux Users.

Bien entendu il ne faut pas ignorer que les périphériques type hdd, usb et graphique dialogues avec le CPU par mots de commandes et l'asm ou autre langage est un simple moyen d'expression.
Pour exemple, Je fais l'analogie entre une carte graphique et le pc comme entre un microcontrôlleur et un "vulgaire" afficheur LCD.
Faut savoir comment fonctionne l'afficheur ensuite on communique avec lui comme on peut (directement par port ou bien par chips-sélect et bus de donnée)

Voici ma vue d'ensemble d'un PC
Est elle bonne a votre avis.
30/07/2010, 19h40
Obsidian

Citation:

Envoyé par fgh39

Pour la programmation en asm PC, je ne sais pas si ce serait utile (je pense que oui) qu'il faut connaitre ce qu'on appelle le mapping d'un pc (bref ce qui est inscrit dans quelque chose qui ressemble a une norme) ==> Là ou sont les adresse des ports (graphique, PCI, usb, rs232, //, hdd, timer, horloge temps réel, mémoire systèmes et son contrôleur, etc ...

Citation:

Voici ma vue d'ensemble d'un PC
Est elle bonne a votre avis.

Si tu programmes en assembleur, il mieux connaître les grandes lignes de l'architecture d'un PC, c'est certain.

Malheureusement, le modèle que tu décris était à peu de choses près celui des ordinateurs 8 et 16 bits, ce qui incluait le PC jusqu'au milieu des années 1990. Celui-ci a énormément évolué depuis et, comme il n'y a pour ainsi dire plus d'autres architectures sur le marché (mais que les constructeurs se livrent toujours une concurrence acharnée), celui connaît un développement exponentiel. Bien qu'officiellement toujours compatible avec le PC original de 1980, je doute qu'il soit encore possible de faire tourner un programme sophistiqué de l'époque sur une machine actuelle sans émulateur.

Le bus PCI, par exemple, est le standard des cartes d'extension. Exit bus ISA, EISA, VLB ou MCA. Aujourd'hui, les périphériques qui y sont connectés s'identifient et déclarent leur propre plan mémoire, lequel est ensuite mappé dans l'espace d'adressage visible par le micro-processeur, et donc l'utilisateur.

En plus, électriquement, les cadences des différents composants que ceux-ci ne sont plus du tout synchronisés : on utilise un FSB pour relier le processeur aux éléments fondamentaux et il y a ensuite un contrôleur-passerelle pour accéder au PCI, par exemple. Et je ne parle pas du bus USB dont le fonctionnement tient plus de la carte réseau que du bus informatique interne d'une carte-mère.

Côté programmation, cela ne change pas grand chose (tant que tu utilises quand même les services d'un O.S. pour faire ce mappage), mais le temps où chaque périphérique utilisait un nombre restreint de ports situés à des adresses fixes (comme les célèbres 220h et suivants pour la Sound Blaster) est définitivement révolu. Sur PC, ceux qui étaient normalisés existent encore par compatibilité mais on ne les utilise pratiquement plus de cette façon.

Citation:

J'avais lu sur une doc que c'est en haut de l'espace adressable par le cpu central. Ensuite les niveaux de droits allant du SU aux Users.

Ça, ça a l'air d'être l'organisation des droits d'accès d'UNIX. C'est purement logiciel et n'a rien à voir avec l'assembleur, ni avec l'architecture matérielle d'un PC.

Citation:

Pour exemple, Je fais l'analogie entre une carte graphique et le pc comme entre un microcontrôlleur et un "vulgaire" afficheur LCD. Faut savoir comment fonctionne l'afficheur ensuite on communique avec lui comme on peut (directement par port ou bien par chips-sélect et bus de donnée)

L'un et l'autre. Une carte graphique va tenir à disposition du programmeur des registres pour la piloter, certes, mais surtout une certaine quantité de mémoire vive. À l'origine, cette mémoire faisait partie de la mémoire centrale de la machine et n'était même pas propre au contrôleur vidéo. Ledit contrôleur lisait cette mémoire de façon linéaire pendant les phases d'inactivité du CPU et générait son signal en fonction de ce qu'il y trouvait. Par conséquent, écrire un octet en mémoire provoquait l'affichage d'un pixel ou d'un caractère (en mode texte).