Discussion :

[kripteks]

Salut à tous.

main.c:

Code :

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

1
2
3
4
5
6
7
8
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
    printf("Hello world!\n");
    return 0;
}

Si je fais: gcc -S main.c
J'obtiens main.s:

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
	.file	"main.c"
	.section	.rodata
.LC0:
	.string	"Hello world!"
	.text
	.globl	main
	.type	main, @function
main:
.LFB2:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$.LC0, %edi
	call	puts
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE2:
	.size	main, .-main
	.ident	"GCC: (Debian 4.8.2-4) 4.8.2"
	.section	.note.GNU-stack,"",@progbits

- Ce code, c'est juste un code représentatif assembleur ou c'est c'est un vrai code qui peut fonctionner ?
-- Si c'est un vrai code (assembleur), est-il possible d'exécuté ce fichier pour avoir le même résultat de mon code C ?
--- Si oui, avec quel commande ? Et niveau portabilité (de code) on a droit à quoi ?

(Mon but est un peu de voir les équivalents de code, pour voir si je peux exploiter directement (seulement) les codes assembleur obtenu.)




Si je fais via cet commande: gcc -S -fno-asynchronous-unwind-tables main.c
J'obtiens un code plus simplifier.

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
	.file	"main.c"
	.section	.rodata
.LC0:
	.string	"Hello world!"
	.text
	.globl	main
	.type	main, @function
main:
	pushq	%rbp
	movq	%rsp, %rbp
	movl	$.LC0, %edi
	call	puts
	movl	$0, %eax
	popq	%rbp
	ret
	.size	main, .-main
	.ident	"GCC: (Debian 4.8.2-4) 4.8.2"
	.section	.note.GNU-stack,"",@progbits

[Neckara]

Bonjour,

- Ce code, c'est juste un code représentatif assembleur ou c'est c'est un vrai code qui peut fonctionner ?

C'est du code assembleur.

-- Si c'est un vrai code (assembleur), est-il possible d'exécuté ce fichier pour avoir le même résultat de mon code C ?

Non, il faut d'abord le compiler (traduire les instructions assembleurs en binaires) avant de pouvoir l'exécuter.

Et niveau portabilité (de code) on a droit à quoi ?

Ton code assembleur sera tout aussi portable qu'un exécutable écrit en C.

[kripteks]

Merci.

Voila j'ai réussi:
gcc -S -fno-asynchronous-unwind-tables main.c
gcc -c main.s -o main.o
gcc main.o -o app

[Obsidian]

Bonjour à tous,

Ton code assembleur sera tout aussi portable qu'un exécutable écrit en C.

Attention à être clair : comme tu le dis, son code source assembleur sera aussi portable que l'exécutable compilé à partir d'un code source en C : c'est-à-dire qu'il ne pourra être exécuté que sur des machines équipées à la fois d'un micro-processeur compatible et d'un système d'exploitation qui l'est aussi, notamment au niveau de l'ABI.

On ne peut malheureusement pas, en revanche, écrire de l'assembleur comme on écrit du C et le porter partout puisque, par nature, c'est le langage propre à l'architecture-cible.

[kripteks]

Bonjour.

J'ai déjà quelque info sur la non-portabilité des codes fait en assembleur car c'est du code trop ciblé (processeur).
C'est pour cela que je m'intérresses aux codes produit de C.


Dans le man de gcc on a ceci:
gcc -E ==> Preprocess only; do not compile, assemble or link
gcc -S ==> Compile only; do not assemble or link
gcc -c ==> Compile and assemble, but do not link


On a plusieurs étape avant d'avoir un executable final.
Le code source au tout début est multi-platforme, l'executable final est ciblé directement à l'os et/ou à la machine (juste le proc ?).

Ce qui m'intéresse c'est de savoir, aux quelles étapes: on a un code modifiable et qui à une portabilié (os et/ou proc), c-à-d:
- pouvoir modifier le code à un stade (plus bas que le code source C)
- modifié ce code, et l'utiliser via gcc, pour avoir un executable (pour os ciblé et/ou processeur (architecture))

[Obsidian]

Le C en tant que code source est censé être portable partout s'il est correctement écrit. C'est même plus ou moins pour cela qu'il a été conçu.

Il est assez fréquent d'entendre dire que le C est « un cran au dessus de l'assembleur », car c'est le langage qui reste le plus proche du fonctionnement du micro-processeur même si les deux langages sont très différents entre eux. C'est d'ailleurs ce qui fait sa longévité : beaucoup de langages de dernières générations produisent des logiciels qui s'appuient sur des infrastructures existantes très importantes.

Quand on redescend la pile des dépendances et que l'on se demande en quoi les premières couches ont été écrites, le béotien propose souvent « en assembleur ». Lorsque c'est le cas, c'est souvent le C que l'on retrouve à la place, car c'est à la fois un langage relativement simple à mettre en place (au vu de ses congénères plus récents), qu'il est très adapté à la production de code objet en « standalone » (par opposition à « hosted »), donc notamment dans le domaine de l'embarqué et des micro-contrôleurs, et parce qu'il s'adapte très bien à tous les types d'architectures, en particulier les Harvard dont la taille des mots n'est pas égale à huit bits (par exemple les PIC12Fxxx).


Passé ce stade, en revanche, tu ne peux plus garantir la portabilité. En effet, le premier stade est la précompilation. Formellement, il va s'agir de développer ou substituer toutes les macros #define par leur valeur définitive. Lorsqu'il s'agit de présélections en tête de programme, ce n'est pas un problème. En revanche, bon nombre d'entre elles sont inscrites dans les fichiers headers de la bibliothèque standard et servent justement à donner les caractéristiques de la plate-forme cible.

Le cas le plus flagrant est celui de limits.h qui te donne les formats et les valeurs limites de tous les types de nombres. Il définit également CHAR_BIT qui donne le nombre de bits occupé par un caractère (8 sur la plupart des machines mais ça n'est pas systématique), lequel caractère forme l'unité de mesure des tailles en langage C. Rien n'est plus petit en C qu'un char, à part les champs de bits au sein des structures.

L'étape suivante transforme directement le code source ainsi corrigé en code assembleur, donc déjà, à ce stade, spécifique au micro-processeur cible et plus du tout portable sur d'autres plateformes.

Le dernier cas que tu cites, l'option « -c » est en fait un traitement post-compilation. Les compilateurs vers le langage machine, donc le C mais aussi n'importe quel assembleur, produisent ce que l'on appelle un fichier objet (rien à voir, en revanche, avec la programmation orientée objet) par opposition au programme source. Ce fichier contient strictement le code compilé correspondant au programme source. Cependant, il n'est pas forcément utilisable en l'état.

Ce fichier objet est une « ressource » qui sera lié à d'autres fichiers objets compilés séparément pour former un tout ET/OU transformé en exécutable en lui ajoutant formellement les bons flags et surtout un point d'entrée. Cette dernière possibilité n'est pas systématique : il pourra aussi devenir une bibliothèque, qui sera utilisé par d'autres projets.

[kripteks]

Un grand merci