[FASM Linux x86] Hello world!

**Luke spywoker** · 11/10/2014, 02h36

Bonjours a la communauté assembleur,
et tout d'abords:

Code :

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
 
;; Programm who write the string "Hello world!\n" on stdout.
 
;; compile the source with commands like:
;; $ fasm hello_world.fasm hello_world.exe
 
 
format ELF executable 3
entry start
 
segment readable executable
 
start:  ;; Entry point 
 
	;; We initialise datas and jump to writer
	jmp writer	;
	jmp returner	;
 
 
main:	 
	;; This is the mainloop ;;
	cmp edi,"9"	; compare edi and value "9"
	je returner	; if equal 9 jump to returner.
	jl writer	; if littler than 9 jump to writer.
 
 
writer:	;; 
 
	;; SYSCALL N°4 = write(fd, string, strlen)
	;; eax contains the SYSCALL number [4] sea: /usr/include/i386-linux-gnu/asm/unistd_32.h
	;; ebx contains the fd arg value.
	;; ecx contains the text to write arg value.
	;; edx contains the text to write length arg value
 
	mov	eax,4		
	mov	ebx,1
	mov	ecx,msg
	mov	edx,msg_size
 
	int	0x80	; Interrupt SYSCALL
 
 
returner:
 
        ;; SYSCALL N°1 = exit(status)
        ;; eax contains the SYSCALL number [1] sea: /usr/include/i386-linux-gnu/asm/unistd_32.h
	;; ebx contains the status arg value.
 
	mov	eax,1
	mov	ebx,0
 
	int	0x80	; Interrupt SYSCALL
 
segment readable writeable
 
msg db 'Hello world!',0xA
msg_size = $-msg

Je suis vraiment débutant et je souhaiterai bénéficier de vos conseils pour bien débuter.
J'ai déjà écrit quelques mini-mini-programmes grâce a des astuces que j'ai vu dans un autre bouquin autre que le livre qui me sert de guide d'apprentissage.

Le livre d'apprentissage est orienter Windows, il prétend que comme Linux est écrit en C c'est un mauvais OS pour l'assembleur.

Qu'en pensez vous ? Est ce vrai ? D'ailleurs je n'ai pas trouver de table des interruptions (ou du moins des références) de mon OS dans les fichiers de celui-ci...

Tout ce passe bien malgré tout mais j'ai commencer a lire le chapitre sur le matériel et j'ai des problèmes concernant le clavier:

En faite le problème vient que le fichier exécutable compiler grâce a FASM me renvoie un signal de faute de segmentation, même pour un:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
format ELF executable 3
entry start
 
segment readable executable
 
start:  ;; Entry point 
 
   mov eax,0x1
   ret

Je ne comprend pas je ne réserve pas de mémoire même pas virtuelle et je me retrouve avec une faute de segmentation.

Faut-il que le code soit parfaitement valide afin qu'il ne génère pas d'erreurs et forme un programme car " mov eax,0x1 puis ret " est parfaitement valide, mais sans explications c'est dur, devrai-je changer de compilateur, y a t il des solution de débogage pour débutant ?

Et du code: press_key.fasm

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
format ELF executable 3
entry start
 
start:
 
 
  org 100h
  @@:
  in al,64h 
  cmp al, scancode 
  jne @b
  ret

Retourne une faute de segmentation aussi.

Les mini-programmes que j'ai fait étaient soit convertis en fichier objet.o puis compiler avec gcc pour le linkage de la libc, soit faisaient appels a des appels systèmes comme le hello world donc directement compiler.

Mais il est aussi dit dans le livre que le processeur itanium dont mon PC dispose n'est pas compatible avec l'assembleur x86. Pourtant jusque ici tout fonctionnait bien avec mon Ubuntu-Gnome i686 correctement. Avec usage des registre généraux, d'index et de pointeurs.

J'attends vos précieux conseils, illuminant ma lanterne, surtout concernant le gestion du clavier (Sous Linux) lequel me plonge dans le ténèbres. Et n'oubliez pas que je ne suis qu'un humble petit débutant.

**Obsidian** · 11/10/2014, 21h19

Bonjour,

Envoyé par Luke spywoker

Le livre d'apprentissage est orienter Windows, il prétend que comme Linux est écrit en C c'est un mauvais OS pour l'assembleur.
Qu'en pensez vous ? Est ce vrai ? D'ailleurs je n'ai pas trouver de table des interruptions (ou du moins des références) de mon OS dans les fichiers de celui-ci...

Ce n'est ni bon ni mauvais, mais les systèmes UNIX sont traditionnellement très orientés C parce que ce sont les mêmes personnes qui ont conçu et écrit les deux. Ensuite, Linux étant par nature open source et fait pour fonctionner sans difficulté sur les architectures les plus exotiques, les programmes se doivent par nature d'être portables, ce qui est presque impossible à réaliser en assembleur, en tout cas sur des architectures à micro-processeur différents.

Pour la « table des interruptions », il faut également comprendre qu'en principe, « interruption » n'est pas du tout synonyme « d'appel système ». C'est cependant une technique assez utilisée, mais c'est surtout le DOS qui, sur PC en particulier, en a fait grand usage, en partie parce qu'elles étaient proposées en grand nombre par les x86 là où les autres micro-processeurs n'en proposaient que deux ou trois, et parce qu'il les utilisaient également lui-même comme vecteurs pour ses propres exceptions, comme la division par zéro.

Sous UNIX ainsi que sur la plupart des OS récents, les appels systèmes vont utiliser une et une seule interruption, qui va principalement servir de call gate. Le numéro de l'appel, lui, est passé dans un registre et l'orientation vers la bonne routine se fait une fois entré en noyau. « INT 80h » a été officiellement dédié à cela si je ne dis pas trop d'âneries et les X86_64 ont même instauré le mnémonique « syscall » qui remplit à peu près la même fonction.

Là encore, il s'agit d'une technique d'appel comme une autre. Sur Amiga, on faisait directement des CALL en ROM sur des vecteurs qui certes étaient rassemblés en début de banque ROM mais qui n'étaient pas plus sophistiqués que de simples procédures dans un programme.

Code :

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

;; Programm who write the string "Hello world!\n" on stdout.

Il y a plusieurs erreurs dans les programmes que tu nous a cités. C'est dommage parce qu'à chaque fois, tu réussis presque à un détail près. En un sens, c'est une bonne chose puisque ça nous permet de voir d'emblée plusieurs causes de panne.

Premier programme :

Code :

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

1
2
3
4
5
start:  ;; Entry point 
 
	;; We initialise datas and jump to writer
	jmp writer	;
	jmp returner	;

Tu fais des JMP, donc ce sont des sauts sans retour. Une fois que tu as sauté vers « writer », le programme ne va pas revenir ensuite à ce point pour et continuer sur « jmp returner ». Pour cela, il aurait fallu utiliser « CALL » et ajouter « RET » à la fin de la procédure « writer ».

Second programme :

Code :

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

1
2
3
4
start:  ;; Entry point 
 
   mov eax,0x1
   ret

Là, c'est l'inverse : ton programme n'est pas en soi appelé avec CALL. Il faut utiliser un appel système (que tu connais) pour en sortir. Un « RET » en fin de programme t'enverra à un endroit indéterminé.

Troisième programme :

Code :

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

1
2
3
4
5
6
7
8
start:
 
  org 100h
  @@:
  in al,64h 
  cmp al, scancode 
  jne @b
  ret

Ça, c'est du DOS uniquement. Ça ne fonctionnera pas sous Linux ni sous Windows en mode natif. Uniquement dans un émulateur.
C'est un programme x86 16 bits (donc loin des 32 et 64 bits des OS modernes) et la manière normale d'en sortir est d'appeler soit l'interruption 20h dépréciée depuis longtemps, soit de faire « MOV AX,4c00h; INT 21h » pour sortir avec un code nul. D'autre part, tu ne pourras pas directement lire les ports d'entrée/sortie depuis un programme en mode protégé sans avoir les privilèges nécessaires pour le faire.

Je ne comprend pas je ne réserve pas de mémoire même pas virtuelle et je me retrouve avec une faute de segmentation.

Une erreur de segmentation est déclenchée à partir du moment où ton programme lit ou écrit en dehors de la zone qui lui a été réservée, et ce électroniquement : c'est le micro-processeur lui-même qui est conçu pour cesser d'interpréter les instructions du programme en cours dès lors que l'accès sort d'une zone dont les limites ont été chargées dans ses registres à l'avance. Ce n'est pas un contrôle logiciel au niveau du système d'exploitation.

Si c'est vrai pour les données, ton programme n'échappe pas non plus à la règle : il s'agit de codes opérations successifs déposés… en mémoire ! Dans le premier cas, tu n'ajoutes aucun code de retour à la fin de des procédures « writer » et « returner ». Il n'y a donc aucune raison qu'elles s'arrêtent. L'exécution va alors se poursuivre à la suite, dans le vide, avec des conséquences imprévisibles et si ça ne plante pas avant, ton programme finira forcément en segfault si l'exécution se poursuit au delà de la fin du segment de code.

Dans le second cas, tu fais bien un « RET » mais à tort. Ton processeur va alors dépiler n'importe quelle information de la pile. Soit celle-ci est déjà vide et le simple fait de la lire la fait sortir de ses limites et déclenche la segfault, soit tu vas lire une valeur invalide et sauter n'importe où en mémoire, probablement en dehors de ton segment, et planter de la même façon.

Mais il est aussi dit dans le livre que le processeur itanium dont mon PC dispose n'est pas compatible avec l'assembleur x86.

Tu es sûr que c'est un Itanium ?
Itanium est un processeur IA64 qui correspond à l'architecture exclusivement 64 bits (non compatible 32) qu'Intel a essayé d'imposer et a finalement abandonné. Aujourd'hui, les processeurs Intel 64 bits (les Core en tous genre, notamment) sont tous à base de X86_64, ou AMD64. C'est AMD qui a lancé une architecture x86 64 bits compatible avec la 32 et c'est elle qui s'est imposée finalement.

**Luke spywoker** · 12/10/2014, 17h56

Grand merci Obsidian pour ces précisions dont je t'avoue que je n'ai pas tout bien compris.

Pour le premier programme:

En faite c'est un arrangement d'un programme légèrement plus évolué afin qu'il n'affiche uniquement que "Hello world!", de ce pourquoi par exemple l'instruction:
cmp esi,9... qui ne sert a rien.

1) un jmp est un saut sans retours je l'avais remarquer mais je ne connaissais pas la function (???) call qui donc d'après ce que j'ai compris retourne dans le flux d'exécution après avoir exécuter la destination du call contrairement a jmp.

2) Ajout du ret pour revenir au flux d'exécution.

C'est un peu mieux comme cela (Moins d'instructions inutiles, alignement du code (?), et utilisation de call a la place des jmp) ?

Code :

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
 
;; Programm who writes 10 times the string "Hello world!\n", prefixed with the iterator number on stdout.
 
;; compile the source with commands like:
;; $ fasm hello_world.fasm hello_world.exe
 
 
format ELF executable 3
entry start
 
segment readable executable
 
start:  ;; Entry point 
 
	;; We initialise datas and jump to writer
	mov edi,"0"	    ; Iterator
	align 1		    ; We align the code on 1 beacuse the next operation copy bytes in esi.
	mov esi, msg_number ; cp byte message in ESI
	align 4		    ; Restore default alignment ???
	jmp writer	    ; We jump because we won't come back.
 
 
main:	 
	;; This is the mainloop ;;
	cmp edi,"9"	; compare edi and value "9"
	jg returner	; if equal 9 jump to returner.
	jle writer	; if littler or equal than 9 jump to writer.
 
 
writer:	;; 
 
	;; SYSCALL N°4 = write(fd, string, strlen)
	;; eax contains the SYSCALL number [4] sea: /usr/include/i386-linux-gnu/asm/unistd_32.h
	;; ebx contains the fd arg value.
	;; ecx contains the text to write arg value.
	;; edx contains the text to write length arg value
 
        mov	eax,4		
	mov	ebx,1
	mov	ecx,esi ; esi contains the numbers bytes sequence.
	mov	edx,1   ; Print only 1 character. 
 
	int	0x80	; Interrupt SYSCALL
 
	mov	eax,4		
	mov	ebx,1
	mov	ecx,msg
	mov	edx,msg_size
 
	int	0x80	; Interrupt SYSCALL
 
	inc	edi 	; Increment mainloop iterator.
 
	align   1       ; Align on 1 because ESI contains bytes.
	inc 	esi 	; Increment number to display
 
	align   4       ; Restore default alignment ???
 
 
	call 	main	; No **ret** instruction because we must return to main not to *start* at the first execution.
 
 
returner:
 
        ;; SYSCALL N°1 = exit(status)
        ;; eax contains the SYSCALL number [1] sea: /usr/include/i386-linux-gnu/asm/unistd_32.h
	;; ebx contains the status arg value.
 
	mov	eax,1
	mov	ebx,0
 
	int	0x80	; Interrupt SYSCALL
 
 
segment readable writeable
 
msg_number db "0","1","2","3","4","5","6","7","8","9"
 
msg db ' Hello world!',0xA
msg_size = $-msg

Programmes N° 2 :
C'est l'instruction ret qui fait que le code valide d'une simple copie (mov de donnée dans un registre) provoque le plantage parce que ret renvoie au flux d'exécution inexistant ?

Programmes N° 3:

C'est du code de mode réel donc ou DOS (16 bits) donc ne fonctionne pas en mode protéger.

D'autre part, tu ne pourras pas directement lire les ports d'entrée/sortie depuis un programme en mode protégé sans avoir les privilèges nécessaires pour le faire.

Mais si je ne peut pas accéder aux port 60h, 61h et 64h comment je vais pouvoir accéder au clavier sous Linux...

Tout c'est bien passer pour moi jusque là (Chapitre 4: Ressource matériels. 1. Le clavier) de mon bouquin d'apprentissage (Que vous avez sûrement lus aussi vue le nombre de ressources en français),

je peut toujours me servir de l'appel système read mais ce n'est pas la manière dont je voit l'avancement de mon apprentissage de l'assembleur,

je préférerai savoir comment accéder aux registres (ports) 60h, 61h et 64h ou une méthode assembleur pur et dur afin d'accéder au clavier sous Linux.

Tu es sûr que c'est un Itanium ?

Oui c'est un bien un Itanium, mais mon OS est un i686 ; peut-être que mes mini-programmes ont fonctionnait car ils n'utilisait que les registre généraux et d'Index...

Mais je dispose d'une autre machine au cas ou.

Désolé de cette maigre réponse mais j'ai attentivement lus le poste de Obsidian.

**Obsidian** · 12/10/2014, 19h50

Envoyé par Luke spywoker

En faite c'est un arrangement d'un programme légèrement plus évolué afin qu'il n'affiche uniquement que "Hello world!", de ce pourquoi par exemple l'instruction:
cmp esi,9... qui ne sert a rien.

Impossible de te répondre hors contexte, sans voir le programme entier.

1) un jmp est un saut sans retours je l'avais remarquer mais je ne connaissais pas la function (???) call qui donc d'après ce que j'ai compris retourne dans le flux d'exécution après avoir exécuter la destination du call contrairement a jmp.

Oui.

Note que cette instruction porte parfois des noms différents selon les micro-processeurs. Sur Motorola, c'est « JSR » ou « BSR », par exemple (« Jump to SubRoutine »).
Elle consiste simplement à empiler le pointeur de programme courant (qui pointe toujours l'instruction suivante) puis à faire un saut ordinaire. C'est équivalent à « PUSH IP; JMP address » (quand c'est possible).

2) Ajout du ret pour revenir au flux d'exécution.

Oui.

Note qu'un « RET » est exactement équivalent à « POP IP ». Ça veut dire qu'il faut que la pile soit propre avant de sortir. Si tu empiles artificiellement ta propre adresse de retour, le micro-processeur n'y verra que du feu.

align 1 ; We align the code on 1 beacuse the next operation copy bytes in esi.

Non, ça c'est une erreur. Oublie ALIGN pour le moment, d'ailleurs.

call main ; No **ret** instruction because we must return to main not to *start* at the first execution.

Dans ce cas, ce n'est pas CALL qu'il faut utiliser. Et si c'est via un CALL que tu y es arrivé, il faudra purger l'adresse de retour.

Programmes N° 2 :
C'est l'instruction ret qui fait que le code valide d'une simple copie (mov de donnée dans un registre) provoque le plantage parce que ret renvoie au flux d'exécution inexistant ?

Oui.
Si tu veux quitter le programme, il faut le faire avec un appel système.

Mais si je ne peut pas accéder aux port 60h, 61h et 64h comment je vais pouvoir accéder au clavier sous Linux...

Exactement de la même façon que tu le fais pour écrire : tu ne vas pas taper directement dans la mémoire vidéo, tu passes par l'appel système « write » qui va se charger d'envoyer ton texte au bon endroit.
Ici, il faut utiliser « read » sur l'entrée standard (numéro de descripteur : « 0 »).

Non seulement c'est exigible en programmation système mais c'est bien souvent nécessaire : que se passerait-il par exemple si tu utilisais un clavier USB ? Que se passerait-il également si tu étais connecté à distance (via SSH par exemple) et pas en local sur ta machine ?

Il y a quelqu'un ici qui a voulu faire la même chose. Voici les raisons pour lesquelles ce n'est pas l'approche à suivre : http://www.developpez.net/forums/d14...r/#post7938230

je peut toujours me servir de l'appel système read mais ce n'est pas la manière dont je voit l'avancement de mon apprentissage de l'assembleur,

L'avancement non, mais c'est aussi utile que write.

Oui c'est un bien un Itanium, mais mon OS est un i686 ; peut-être que mes mini-programmes ont fonctionnait car ils n'utilisait que les registre généraux et d'Index...

Tu peux nous donner le modèle exact de ce processeur ? Les Itanium ne sont pas censés être compatibles avec les x86 du tout. Les x86_64, si.
Tu travailles en natif ou en émulateur avec une machine virtuelle ?

**Luke spywoker** · 13/10/2014, 04h00

Impossible de te répondre hors contexte, sans voir le programme entier.

Il y a mésentente: Le premier programme montré (qui affiche "Hello world!" 1x) est issue du second (Qui affiche 10x "Hello world!") juste pour dire bonjours a la communauté assembleur.

En faîte tu a semer le doute concernant mon processeur et j'ai vérifier:

C'est un modèle: Intel Core i7 3770 (Ivy Bridge). J'ai dû croire que le "i" voulais dire Itanium quand je l'ai acheter. car je cherchais un processeur abordable mais puissant...

Non, ça c'est une erreur. Oublie ALIGN pour le moment, d'ailleurs.

J'ai écrit un mini programme se servant de rdtsc pour calculer la différence en alignant le code ou pas
(simplement en (dé)commentant les directives align)
et en l'exécutant plusieurs fois il s'avère que c'est utile en termes de performances d'aligné le code !

D'ailleurs l'assembleur aussi car j'ai fait une loop jusqu'a la valeur maximale d'un DWORD qui inclus une autre boucle sur un WORD et le programme retourne de suite le résultat sans attente, trop puissant !!!

Je sais que rdtsc n'est pas le meilleur moyen de calculer les performances d'un seule programme, a cause du scheduling.

Mais je suis ton conseil et ne fait pas attention a l'alignement du code pour l'instant.

Concernant la suite je suis toujours aussi frustré que le livre d'apprentissage se serve du mode réel dans ses exemples de code (ce qui ne me permet pas d'évoluer au niveau du code contrairement a la théorie) car j'ai attaquer le chapitre concernant AVG. et donc le code suivant:

Code :

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Programm to print an palette entry ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
;;   compile the source with commands like:
;;   $ fasm print_an_palette_entry.fasm print_an_palette_entry.o
;;   $ gcc print_an_palette_entry.o -o print_an_palette_entry.exe
;;   $ print_an_palette_entry.exe
 
format ELF
 
include 'ccall.inc'
 
section '.text' executable
 
 public main
 
 extrn exit
 extrn printf
 
 
init:
 
  mov 	al,13h	; select display mode
  int	10h	; BIOS VGA interrupt: function for VGA registers abstraction.
                ; Not **always** compatibles with 32 bits (protected) mode.
 
get_palette:
 
 
        ;; The idea was to call this code in a loop to display all palette entries 
        ;; instead of only the case 45.
 
	mov 	dx,3c7h 	; DAC Adresse Read register 
	mov 	al,45           ; pallete case number
	out	dx,al           
	mov 	dx,3c9h         ; DAC Data register. 
 
	;; Now dx contains the color value from palette entry N° 45.
 
	in	al,dx            
	mov 	[red],al 
 
	in	al,dx 
	mov 	[green],al
 
	in	al,dx 
	mov 	[blue],al 
 
	;; The VGA controller is in read mode (3c7h) and point to next palette entry: N° 46.
 
	ccall printf, print_palette_value, red 
	ccall printf, print_palette_value, green 
	ccall printf, print_palette_value, blue
 
 
returner:
 
	ccall exit,0
 
 
main:
 
  call 	init
  call 	get_palette
  call  returner	
 
section '.data' writeable
 
 print_palette_value db "value is: %s",0xa,0
 
 red rb 1   
 green rb 1
 blue rb 1

Me retourne une erreur de segmentation parce que soit:

- Je ne peut pas lire directement des registres du DAC (Digital Analog Converter): 3C7h (READ), 3C8h (WRITE), 3C9h (DATA) ?
- La réservation et les pointeurs ne se font pas comme ca ?
- Le format string est faux par rapport a l'argument ?

En espérant ne pas trop avoir dit de bêtises. (Si vous voulez je vous montre mon torchon de porcinet censé afficher une fenêtre rouge ?)

Merci pour vos réponses éclairées.

**Forthman** · 13/10/2014, 07h40

Hello,

un i7 c'est pas ce qu'il y a de plus abordable, mais performant oui

Si tu veux utiliser les exemples du livre (réel 16 bits) je te conseille d'installer un émulateur genre DosBox
Ca te permettra de te familiariser avec le processeur, et tu ne seras pas frustré de ne pas pouvoir utiliser les interruptions et les ports I/O

Par contre, si ton but est de créer des programmes pour des OS comme Linux ou Windows, je pense que tu peux te servir de ton livre pour caler
une porte (par exemple)

**Luke spywoker** · 13/10/2014, 08h07

Merci Forthman pour ces précision je vais voir si je trouve DosBox pour Linux.

Mais pour l'instant j'ai du neuf:
Le code suivant ne retourne pas de faute de segmentation mais ne sert a rien car:

Code :

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
 
 
 
format ELF
 
include 'ccall.inc'
 
section '.text' executable
 
 public main
 
 extrn printf
 
main:
 
  mov ax,13h
  int 80h
  mov [video_ptr],0A000h ;
 
  mov 	dx,3c7h ;
  mov 	al,40
  ;out 	dx,al
  mov	dx,3c9h
 
  ;in	al,dx 
  ;mov	[red],al 
 
  ;in	al,dx 
  ;mov	[green],al 
 
  ;in	al,dx 
  ;mov	[blue],al 
 
  ;ccall printf, print_palette_value, red 
  ;ccall printf, print_palette_value, green
  ;ccall printf, print_palette_value, blue 
 
 
section '.data' writeable
 
 print_palette_value db "value is: %s",0xa,0
 
 red rb 1
 green rb 1
 blue rb 1
 
 video_ptr rd 320*200

les ordinateurs que j'ai a disposition ne supoortent pas les commandes out et in apparament.

Car si l'on décommente une instruction in ou out dans le code précédent la sanction est immmédiate:
Segmentation fault (core dumped)

Pouvez vous me dire, si vous le désirez bien, si il existe peut être des équivalents pour:
out: écrire la valeur de al dans le port pointé par dx.
in: Lire la valeur de pointé par dx dans al.

Merci pour vos réponse éclairées.

**Forthman** · 13/10/2014, 09h47

DosBox est présent dans les "gestionnaires de logiciels" des Linux courants.

Ce ne sont pas tes ordinateurs qui ne veulent pas de IN et OUT mais tes OS

Et non, il n'y a pas d'équivalent, pour la simple et bonne raison qu'aujourd'hui il n'est plus possible de faire ainsi

**Luke spywoker** · 13/10/2014, 12h21

Reçu 5 sur 5 Forthman,
voila une réponse claire, net et précise.
Ce qui nous amène a un gros problème... la syntaxe Intel n'est pas bien comprise par les OS Linux, normal d'un coté, vue que le GNU Assembler est de rigueur sur Linux.
Il ne me reste plus que a changer de cap.
Ne vous inquiétez pas je trouverai mon chemin.
Merci pour vos réponses éclairées.

**Obsidian** · 13/10/2014, 23h27

Envoyé par Luke spywoker

Reçu 5 sur 5 Forthman,
voila une réponse claire, net et précise.
Ce qui nous amène a un gros problème... la syntaxe Intel n'est pas bien comprise par les OS Linux, normal d'un coté, vue que le GNU Assembler est de rigueur sur Linux.

Tu peux lui demander à le faire en faisant débuter ton bloc d'instructions par la ligne « .intel_syntax noprefix » (avec le point au début). Si pour une raison ou une autre, tu veux revenir à la syntaxe AT&T (utile dans le cas d'asm inline dans un programme C), tu écris « .att_syntax ».

**Luke spywoker** · 14/10/2014, 08h35

En faîtes mon plan est de lire le bouquin sur l'assembleur 64bits que j'ai acheter en même temps que le livre d'apprentissage, qui est en anglais.
Dont j'ai d'ailleurs lus déjà 4 chapitres, mais il est difficile a lire et ne semble pas très complet et la syntaxe et également celle d'Intel.
Ca faisait partie de mon plan.

Une question cependant:

Forthman a dit que:

Ce ne sont pas tes ordinateurs qui ne veulent pas de IN et OUT mais tes OS

Mais est-ce vrai ?

Ou ce ne sont pas plutôt les ports que je pointe avec dx qui ne sont pas accessible.
Formuler autrement: est-ce que normalement les instructions out et in fonctionne correctement si on les utilises correctement sous Linux ?

Merci pour vos réponses éclairées.

**Forthman** · 14/10/2014, 08h39

Bien sûr, avec les privilèges qui vont bien, il est possible d'accéder aux ports.
Mais pour des raisons de sécurité et de portabilité, seuls les drivers devraient pouvoir le faire.

En résumé, pour accéder aux périphériques, il faut utiliser les fonctionnalités de l'OS

**Obsidian** · 14/10/2014, 14h55

Envoyé par Luke spywoker

Ou ce ne sont pas plutôt les ports que je pointe avec dx qui ne sont pas accessible.
Formuler autrement: est-ce que normalement les instructions out et in fonctionne correctement si on les utilises correctement sous Linux ?

Ce que Forthman veut dire, c'est que tu travailles en mode protégé : les limitations qui s'appliquent à la mémoire et qui provoquent les segfaults sont également valables a fortiori sur les ports d'entrée-sortie.

La manière normale de les utiliser est donc de travailler en mode noyau, au niveau des pilotes, là où le droit de le faire est automatiquement acquis. Il existe toutefois, sous Linux, un appel système qui te permet de demander à écrire dans certains ports, mais c'est plus pour bricoler, à mon avis, que pour écrire des applications sérieuses. En tout état de cause, le temps d'accès à ces ports dans ce contexte n'est pas garanti.

Par ailleurs, je t'ai donné un lien dans le commentaire № 4. L'énumération que l'on trouve derrière n'avait pas pour but de ridiculiser le primo-postant, mais de mettre en évidence toutes les difficultés que tu vas rencontrer à essayer d'exploiter le clavier de cette façon sur un système multi-tâches. On rappelle que la personne en question a voulu faire la même chose que toi, à savoir exploiter le clavier sur PC via les ports 60h à 64h.

Ça reste intéressant dans le principe, mais tu as alors trois options à ta disposition :

Soit tu travailles en 16 bits et tu fais des programmes pour DOS. C'est excellent pour apprendre, tu as le droit de contrôler toute ta machine comme tu l'entends et tu ne te soucies pas du mode protégé. Par contre, il te faudra travailler avec DosBox qui est en quelque sorte un émulateur de PC sur PC, soit tu installes carrément une VM et tu y colles une vraie version de DOS, telle que freedos. Ça aura beau être émulé, tu travailleras quand même exactement dans les mêmes conditions qu'à l'époque bénie des démos. Autre avantage, dans un cas comme dans l'autre : lors des nombreux plantages que tu vas rencontrer, il te suffira de redémarrer DosBox ou ta VM plutôt que rebooter ta machine à chaque fois. Enfin, tu pourras bénéficier à la fois des outils de développement moderne (dans le vrai OS) et des outils de l'époque tels que Turbo Debug (mauvais exemple parce que c'est un logiciel propriétaire) ;
Soit tu travailles en 32 ou 64 bits sans OS : c'est très stimulant également, mais c'est beaucoup de travail : il faudra commencer par écrire un secteur de boot sur un média donné puis s'arranger pour lire le reste puis, éventuellement, lancer le mode protégé et, de là, écrire en quelque sorte un mini-OS. Là encore, je te suggère une VM pour commencer parce que c'est pénible de rebooter à chaque fois ou — mieux — une seconde machine à proximité ;
Soit tu décides de travailler directement en conditions normales mais en faisant de l'assembleur. Là, tu n'as pas le choix : il faut faire de la programmation système, que celle-ci se fasse en C ou assembleur. Il est donc nécessaire de respecter ses règles et d'écrire des programmes faits pour fonctionner dans un environnement multi-tâches.

Concernant le point № 2, je m'étais donné, il y a deux ou trois ans, un objectif assez stimulant de mon point de vue : écrire un programme complètement autonome qui irait piloter ma sonorisation 5.1 USB défectueuse, et le tout in situ, en utilisant un ancien laptop à base de P4 pour exécuter le tout pendant que je développais sur ma machine principale. L'idée était à la fois d'y avoir accès directement pour être sûr de ce que je lisais et de me familiariser avec le fonctionnement à bas niveau de l'USB en général. Dans le principe, j'ai décidé de ne suivre « qu'une seule branche de l'arbre », c'est-à-dire partir vraiment de zéro, et développer les pilotes pour les périphériques nécessaires à l'accomplissement de l'objectif, mais exclusivement ceux-ci, à l'exception de tout le reste donc, et en me limitant à ce qui était nécessaire, qui à étoffer ensuite une fois l'objectif atteint.

Ça m'a demandé d'aller retrouver les spécifications techniques des différents composants de la machine de l'époque, mais également de me plonger dans le bus PCI lui-même, d'en faire l'énumération des périphériques et de mapper ceux-ci au bon endroit en mémoire, etc. Je ne suis pas allé jusqu'au bout parce que ça prenait vraiment trop de temps, mais ça m'a quand même demandé d'écrire une console minimaliste, avec barre de status et invite de commande, etc. Si j'en ai fait une bonne partie en assembleur, j'ai vite embrayé ensuite sur le C quand il s'agissait de gérer la console parce que faire un printf avec tous ses paramètres est aussi long à mettre en place qu'à utiliser en conditions normales ensuite. Par contre, j'ai vite mis en place un BOOTP/PXE pour éviter d'avoir à jongler en permanence avec une clé USB ou une disquette entre les deux machines : un câble réseau, un dépôt dédié avec un script pour les mettre à jour juste après la compilation et une touche spéciale dans le mini-OS pour provoquer un reboot immédiat, et j'étais parti pour plusieurs nuits. :-)

**Luke spywoker** · 14/10/2014, 22h51

Grand MERCI beaucoup Obsidian pour toutes ces précisions et d'avoir pris le temps de les rédiger ca fait plaisir que quelqu'un se préoccupe de moi.

Ayant suivis un gros revers de popularité de la part de la communauté python pour un tutoriel (plutôt un HOW-TO) et d'un module d'aide a la programmation 3D dont j'ai consacré environ 6 mois (avec l'étude d'OpenGL et de son implémentation python comprise) Qui n'a pas eu un grand succès. d'ailleurs existe-t-il une implémentation d'OpenGL pour l'assembleur (Je n'en suis pas là) ?

Pour résumer l'évolution de mon apprentissage j'ai remarquer plusieurs choses:

-Effectivement l'écriture dans les ports n'est pas possible en mode protégé, j'ai définitivement abandonner le coté matériels de l'assembleur. (Ce qui nous ramène au GNU C pour la programmation système ou de drivers même.)

-La seule interruption accepter est 0x80, bref syscall si l'on veut.

-Je suppose que la programmation en assembleur pour le coté applicatif (pas les drivers ou autres trucs matérielle) fait beaucoup usage d'appels de fonctions système.

-J'ai chercher un peu des tutoriels sur le net et j'ai appris deux ou trois trucs comme dépiler la pile au départ du programme et ce qui en suit...
Pouvez vous m'en indiquer si vous en avez dans vos marques-pages sachant que je supporte FASM et NASM et que je suis néophyte. Je vous remercie d'avance.

-Et il n'y a pas grand monde dans le forum assembleur ? Car un nouveau venus est souvent accueilli par plus de 2 intervenants.

Encore merci de m'avoir mis les points sur les î et les barres sur les B.

Obsidian est vraiment très gentil et Forthman est directe et efficace, merci pour votre accueil les gars en espérant qu'on continuera comme ca.

Merci pour vos réponses éclairé.

**Forthman** · 14/10/2014, 23h06

bien c'est que l'assembleur aujourd'hui... c'est plutôt mort

Normalement on est un peu plus que deux ici, mais dès le départ il était assez évident que ça n'irait pas très loin...
Ce n'est pas une critique envers toi hein (moi aussi je suis gentil

) La plupart des "débutants" qui débarquent ici
avec de grandes idées car "on leur a dit que l'assembleur c'était le top du top" lâchent l'affaire rapidement.
Je tiens d'ailleurs à te félicité pour avoir été aussi tenace

(non, ce n'est pas une blague)

Et encore une fois je tire mon chapeau à Obsidian qui consacre énormément de temps pour répondre à toutes ces questions.
Quelle patience !

**Obsidian** · 15/10/2014, 02h50

Envoyé par Luke spywoker

Grand MERCIAyant suivis un gros revers de popularité de la part de la communauté python pour un tutoriel (plutôt un HOW-TO) et d'un module d'aide a la programmation 3D dont j'ai consacré environ 6 mois (avec l'étude d'OpenGL et de son implémentation python comprise)

C'est malheureusement une chose à laquelle on est assez vite confronté et qui refrène bien des ardeurs. Mais ça reste une bonne chose en soi puisque cela pousse les gens à être exhaustifs dans leurs recherches et être irréprochable sur leurs affirmations. C'est d'autant plus important quand on commence à se faire un nom parce que les gens prennent alors ce que l'on dit pour argent comptant. Il devient alors vital d'être parfaitement exact.

Qui n'a pas eu un grand succès. d'ailleurs existe-t-il une implémentation d'OpenGL pour l'assembleur (Je n'en suis pas là) ?

L'assembleur consiste à utiliser le jeu d'instruction du micro-processeur. À partir du moment où tu utilises une ressource exécutable en langage machine, tu peux l'appeler depuis un programme en assembleur. En l'occurrence, l'API d'OpenGL est écrite en C. Il faudra donc respecter cette convention et utiliser éventuellement les macros adaptées à cet usage (« INVOKE ») mais dans l'absolu, c'est faisable.

Par contre, par nature, l'assembleur n'a pas d'ABI normalisée en soi. Programmer en assembleur, ça ne veut pas forcément dire « utiliser les interruptions » (ce qui est d'ailleurs une déformation largement due au PC).

-Effectivement l'écriture dans les ports n'est pas possible en mode protégé, j'ai définitivement abandonner le coté matériels de l'assembleur. (Ce qui nous ramène au GNU C pour la programmation système ou de drivers même.)

Elle l'est (et heureusement) mais à condition d'être dans un segment doté des bons privilèges. Et quand elle est interdite, c'est pour de bonnes raisons.

Accéder directement aux ports d'entrée/sortie quand on travaille sur un système multitâche peut mettre celui-ci dans un état très instable. Si tu veux le faire quand même, commence par travailler dans une VM. Tu pourras tout casser à volonté, ça ne dépassera pas ses frontières.

-La seule interruption accepter est 0x80, bref syscall si l'on veut.

C'est un poil plus subtil. « INT 80h » est bien l'interruption favorite en 32 bits pour faire ce genre d'opération et je crois même qu'elle est préconisée par Intel (j'ai la flemme d'aller compulser le manuel) mais ce n'est pas une obligation non plus. Windows a décidé d'utiliser INT 2E pour ses appels.

« SYSCALL », par contre, est une instruction introduite par AMD64, qui va de pair avec SYSRET, et qui est l'alter-ego de SYSENTER/SYSEXIT définies jadis par Intel. Tout est décrit ici : http://wiki.osdev.org/Sysenter

La finalité de ces instructions est la même mais avec un objectif avoué et en tâchant de réduire la latence due au changement de mode.

-Je suppose que la programmation en assembleur pour le coté applicatif (pas les drivers ou autres trucs matérielle) fait beaucoup usage d'appels de fonctions système.

En réalité, pas tant que ça. Certes, tu vas traverser différentes couches qui vont s'appeler successivement et au final, le dernier appel sera un appel système ou un pilotage direct du matériel (si privilèges acquis). Mais autant que faire se peut, on essaie de limiter les recours au système et essayer de se débrouiller seul tant que c'est possible. D'abord, parce que les appels systèmes sont coûteux et que passer en mode noyau (et en revenir) est relativement lent.

C'est le rôle par exemple de la bibliothèque standard du C et de ses entrées-sorties : quand tu fais un printf(""), la majeure partie du traitement est effectuée directement dans l'espace mémoire du processus et le résultat s'accumule dans un buffer. Ce n'est que lorsque ce buffer est plein ou qu'un envoi immédiat a été demandé que l'appel système a réellement lieu.

En outre, tous les appels système sont aujourd'hui bufferisées par la glibc, ne serait-ce que pour convertir la convention d'appel C vers un véritable appel à base de SYSENTER, INT80h ou SYSCALL, faire le distingo entre les versions 32 et 64 bits, et gérer proprement le retour de paramètres.

Envoyé par Forthman

Et encore une fois je tire mon chapeau à Obsidian qui consacre énormément de temps pour répondre à toutes ces questions.
Quelle patience !

Merci pour ces appréciations. Tes interventions sont très appréciées dans cette rubrique également.

**Luke spywoker** · 15/10/2014, 16h01

Salut les gars, ca gas semble-t-il pour moi, j'ai lu un très bon tutoriel et je suis content de ce que j'ai appris.

Mais une question me turlupine:

En utilisant la dosbox (qui n'est pas facile au début) est-ce-que cet émulateur permet vraiment de provoquer des événements au niveau du matériel ?
Car c'est un émulateur et Obsidian a dit aussi que l'on pouvait intégrer un système DOS dans une VM mais tout ca me semble incertains concernant le binding avec le véritable PC ( Le matériel) ou l'émulateur émule le matériel aussi comme ca pas d'inquiétude ?

PS: et Issam Abdallah alors ? celui qui a écrit ce tutoriel.
Et les autres auteurs de tutoriels assembleur disponible sur le site, ils ne sont plus de la partie (GAME OVER ?).

**Kannagi** · 15/10/2014, 17h01

Une VM émule bien le matériel PC sinon il ne serrait pas possible installé un quelque OS dessus , bref je doute que tu ferait une instruction exotique qui ne serait pas émulable par rapport a des OS comme Windows ou Linux.
De même que pour Dosbox qui émule beaucoup de logiciel d'antan donc je pense qu'il n'y a pas inquiétude a avoir.

Sinon pour le forum il y a peu de personne , mais c'est normal il y a aussi peu de demande et intervenant et assembleur est beaucoup moins utilisé aussi.

**Obsidian** · 15/10/2014, 18h56

Envoyé par Luke spywoker

En utilisant la dosbox (qui n'est pas facile au début) est-ce-que cet émulateur permet vraiment de provoquer des événements au niveau du matériel ?
Car c'est un émulateur et Obsidian a dit aussi que l'on pouvait intégrer un système DOS dans une VM mais tout ca me semble incertains concernant le binding avec le véritable PC ( Le matériel) ou l'émulateur émule le matériel aussi comme ca pas d'inquiétude ?

Dosbox est disponible en standard sur la plupart des distributions de Linux. Il te suffit d'installer le package pour obtenir un environnement déjà préconfiguré. Essaie-la et fais-toi ton opinion.

Non seulement, comme le dit Kannagi, un certain niveau d'émulation hardware est exigible ne serait-ce que pour que ça marche, mais DosBox a été spécialement conçue pour faire fonctionner aussi proprement que possible les logiciels DOS qui, eux, tapaient beaucoup plus souvent dans les registres hardware que le font les applications actuelles. En particulier les jeux. Dans ce dernier cas de figure, d'ailleurs, les événements clavier doivent être rapidement et proprement émulés mais également le son. DosBox propose plusieurs cartes son très à la mode à cette époque, telles que différentes versions de la Sound Blaster et est capable de reproduire ses effets via les pilotes de ton système d'exploitation, donc vers n'importe quelle carte moderne.

Tu noteras d'ailleurs que le problème est exactement le même (et réglé de la même façon) avec les machines virtuelles qui sont devenues si courantes aujourd'hui (peu de gens se rendent réellement compte du travail que cela demande pour que ça marche).

PS: et Issam Abdallah alors ? celui qui a écrit ce tutoriel.
Et les autres auteurs de tutoriels assembleur disponible sur le site, ils ne sont plus de la partie (GAME OVER ?).

Il suffit de consulter la page du profil de l'individu concerné. Mais effectivement, les époques passent et les gens finissent toujours par se tourner vers de nouveaux horizons.

**Forthman** · 15/10/2014, 22h38

Je suis un adepte de DosBox, comme le dit Obsidian, il est disponible dans les Ubuntus et autres distris compatibles Debian.
Et une simple "sudo apt-get install dosbox" suffit à l'installer

Après, il faut juste monter un répertoire comme étant l'unité C: et ça roule

Les ports I/O sont tous très bien gérés, sous réserve d'avoir les droits.
donc tu peux oublier les accès disques, mais le clavier (IO 60h) fonctionne a merveille,
souris pareil, les modes VGA aussi, parfois ça peut planter avec les modes VESA,
ou lors de basculement plein écran...

Le mode protégé fonctionne aussi (doom fonctionne très bien dessus

)
par contre, le "unreal mode" ne fonctionne pas (mais c'est de la bricole alors c'est un peu normal non

)